Skip to content

Setup your CI

B. K. Oxley (binkley) edited this page Apr 3, 2024 · 15 revisions

Length of Feedback Cycle

Setup your CI

Your CI is your "source of truth" for successful builds. Your goal: Everyone trusts a "green" CI build is solid.

When using GitHub, a simple starting point is ci-earthly-gradle.yml or ci-earthly-maven.yml (GitLab is similar, but as this project is hosted in GitHub, there is not a simple means to demonstrate CI for GitLab). This project includes a workflows for Gradle and Maven in a container such as Earthly.

If you use GitLab, read about the equivalent pipelines in GitLab CI/CD, or for Jenkins in Pipeline.

When publishing your project, consider Publishing Java packages with Maven for GitHub, or equivalent for other CI systems. Do not publish from local builds. Seriously, relying on local publishing of artifacts will lead to headaches and problems, and back to it worked on my machine issues.

For GitHub, note the limitations of Download from Github Package Registry without authentication.

Save your CI artifacts

It is helpful to preserve your build artifacts from CI, for example, to download built jars from different CI runs for comparing their behavior between commits without needing to rebuild locally, and also to confirm that your local build makes the same jars as CI does.

The "Build with Gradle" and "Build with Maven" CI workflows each provide a download named "jars", and the Maven build a "site" download.

There are services to provide links to the most recent build artifacts. One example is nightly.link (this is not an endorsement). You can use these links in your README.md or share as makes sense. An example is downloading the Maven-built jar from this project.

Tips

  • To disable ASCII colorizing printing as control sequences in CI, or Gradle trying to overwrite lines (control sequences make for hard-to-read CI logs), a simple approach is to use an environment setting:
    TERM=dumb
    This does not make sense for local builds, and your CI system (eg, GitHub) may manage this problem already
  • With Gradle, use the --warning-mode=all flag for CI: this shows all warnings Gradle generates, not just a summary. See Showing or hiding warnings for details
  • With Maven, use the --no-transfer-progress flag for CI: this avoids spamming CI logs with download progress messages
  • For GitHub Actions, you may find a tool like act useful for running CI actions locally (it may not work for all projects, however, depending on your actions)
Clone this wiki locally