Versions Compared

Old Version 4

changes.mady.by.user Justin Florentine

Saved on

compared with

New Version 5

changes.mady.by.user Justin Florentine

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Porting over the functionality from CircleCI was tedious, but fairly straightforward. Current progress can be seen on in this pull requestfork. The design of small components combined with access to the runners via self-hosting, made the development process pretty accessible. Being able to tie into the GitHub event stream allows for improved and simplified release processes that can be adopted incrementally.

...

Once the PR is approved, the following can be run in parallel.

  • run acceptanceTestsPermissioningintegrationTests
  • run acceptanceTestsCliqueBFTacceptanceTests
    • run
    integrationTests
    • acceptanceTestsPermissioning
    • run
    acceptanceTests
    • acceptanceTestsCliqueBFT
  • run referenceTests

Test results can then be posted back to the PR, and any failures would prevent merging . If all pass, then the following artifacts are created, unique to the commit for this workflow.

  • tarball created
  • zipfile created
  • docker images created

Should a release be decided on for this commit, the creation of a draft release would trigger:

  • publishing of prior created artifacts with the release name and an RC1 suffix.
  • creation of a release branch, should additions be necessary for an RC2.

When a release comes out of draft, and is approved:

...

into main.


Merging to Main

Merging 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 acceptanceTested status.
  • integration test checks have passed on the merge result, and the PR has an integrationTested status.
  • reference test checks have passed on the merge result, and the PR has a referenceTested 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. 

main  and release-*  named branches will require the above checks before merging.


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 should 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

...

.