You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Besu's CI process is broken into reusable phases, and defers long-running and expensive phases till as late and infrequently as possible, while still ensuring maximum quality checks. CI/CD used to be implemented via CircleCI, but it has since been migrated to Github Actions in an effort to reduce cost as well as be consistent with the majority of Hyperledger projects.

What this means for users

Users should not notice anything different, other than new delivery urls for Besu releases. Github Packages and the Github Container Registry will be the source for all binaries, but all releases will still be communicated out to users via Github releases.

What this means for developers

  • Deferral of advanced CI/CD testing. As a cost reduction measure (CircleCI for Besu costs a little under $2K USD per month), long running tests are only executed after PR peer review. Details on how to run those tests locally are now included in the pull request template, and they can also be manually initiated on the CI/CD infrastructure.
  • Releases are now much more fully automated. Any maintainer may create a release from main  or a release-*  named branch (hereafter referred to as "releasable branches") using standard Github tools.  That process is outlined in more detail below.
  • Speed. Breaking up the various workflows into smaller pieces using test splitting results in much greater parallelization, and hence shorter overall runtimes.

How does it work?

On new PR open, draft or otherwise, the pre-review workflow is run.

  • check for repo compliance via repolinter
  • check for source code formatting via spotless
  • check gradle tooling validation.
  • compile all code
    • then validate javadocs- done later because this depends on bytecode output.
  • run unitTests
    • test suites are grouped by gradle subproject, and run in parallel
    • any test failures will be annotated on the PR.

Overall this looks like:


It takes about 15 minutes, end to end, but if we can be smarter about splitting the unit tests we could easily cut that in half. 

Once the PR is approved by any Besu Maintainer, the workflow executes the more expensive test suites before allowing a merge to a releasable branch.

  • run integrationTests
  • run acceptanceTests
  • run referenceTests

Test results can then be posted back to the PR, and any failures would prevent merging into main.  You'll notice that the acceptanceTest phase no longer requires us to separate out private network tests.  We divide all these tests across 16 runners in parallel, and it completes in 17 minutes. You'll also find test results attached to the workflow run, and a summary of how each test shard performed. This is also the case for integration and reference tests as well.

Merging to Main

Merging to main or any release-* named branch should be denied until:

  • pre-review checks have passed on the merge result, and the PR has a pre-review  status.
  • PR has an approval from at least one project maintainer.
  • acceptance test checks have passed on the merge result, and the PR has an acceptance-tests status.
  • integration test checks have passed on the merge result, and the PR has an integration-tests status.
  • reference test checks have passed on the merge result, and the PR has a reference-tests status.

Once all these are confirmed, the PR may be merged, and all statuses should be transferred to the corresponding commit on the target branch. That commit would now be considered releasable. 


Planned Release Process Design

Current release process supports (and encourages) releasing directly from main, but does allow for the creation of release specific branches for hotfixes or interim releases which must not include what is currently on main.

When a github release is created (pre-release or otherwise) then the following artifacts are built, and attached to the release:

  • tarball - release description has the sha256 sum for this file appended to it.
  • zipfile - release description has the sha256 sum for this file appended to it.
  • docker images created and tagged.

All artifacts will have the version number specified in the created github release.

Example release can be seen here.

  • No labels