Release Candidate GitHub Workflows

GitHub Workflows for Building a Release

There are three workflows which are intended to be used in the preparation of a release, and they all rely on Helios's release candidate Branch & Tag naming conventions.

1. Branches for Release Candidates are numbered sequentially, and are of the form rc16nnn where nnn is the release number.
2. Tags for the release candidates are of the form 1.6.nnnh.b where nnn matches the release candidate branch. h is the hotfix number, and b is the sequential build number.

The Workflows

Click to see Screenshots

Image showing the three workflows

Prepare Environment for New Release Candidate

This workflow is triggered manually and only runs against the master branch. It checks previous candidate release branches on remote and then creates a new branch with a name incremented by 1. This new branch is based on master. Finally it creates an initial tag for the release builds.

This workflow should only be triggered once per release.

Click to see Screenshots

How to manually trigger the Prepare against the master branch.

Example

The last release of Helios to ship was 1.6.789 and was released from the release candidate branch rc16789. The final build for rc16789 was tagged with 1.6.7892.3 ie two hotfixes and 3 builds.

When the Prepare workflow runs, it will create a new branch called rc16790 from master and push an initial tag for the release candidate of 1.6.7900.0

Build Release Candidate & Create MSI Files

This workflow is intended to produce a new Helios build on a push to a release candidate branch. On successful build and packaging, the files are zipped and cached for use by the publishing workflow.

Click to see Screenshots

Successful build will save the build logs and zipped msi packages as assets. The zipped msi files are also saved in a cache for use by the publish workflow

More detailed view of the steps completed. Clicking on the step will provide more information.

Example (cont)

Pushing a commit to branch rc16790 will result in the Build Release Candidate & Create MSI Files workflow running. This should identify the next tag which would be 1.6.7890.1 and a successful build and package will result in this being the release in the msi files. In the artifacts for the workflow run will be the zipped msi files created at the end of the build, as well as the build logs. There should also be a new cache entry called Helios-installers-1.6.7900.1 which is used by the new workflow.

Publish Draft Release Workflow from Zip files held in Cache

This workflow needs to be triggered manually on a Release Candidate branch which has a name in the form "rc16nnn". The workflow attempts to find a valid cache containing the installer files built by the previous Build workflow, and then it creates a new draft release and uploads the installer files. The workflow will also create a new build tag with the next sequential number. Correct Tag and Branch naming conversions are critical to the success of this workflow.

Click to see Screenshots

The Publish workflow needs to be triggered manually against the Branch for the release candidate.

The Cache display shows the cache created by the build workflow and used by the Publish workflow. Notice that the cache name contains the release number.

Example (cont)

When the Publish workflow is triggered against branch rc16790, the workflow attempts to find the last release that was shipped It decrements the current branch name to obtain rc16789 and then looks for the most recent tag matching the filter 1.6.789?.*. The workflow uses this tag to determine all of the commits between this last release tag 1.6.7892.3 and the current tag 1.6.7900.1, and populates this information into the skeletal draft release. The Publish workflow then pushes the Tag for the new release to GitHub.

Notes

1. NuGet on the builds will cause the compile steps to fail if there is an unresolved CVE on the package. The typical action here is to update the package to resolve the vulnerability, and hope everything still works.
2. The Build workflow does not push a tag to GitHub for the new release, so a second build (without a successful Publish) will reuse the same release number and the same cache entry.
3. If you need to re-run the Publish workflow following a previous successful workflow execution, you will need to manually delete the tag for the build in GitHub otherwise the workflow will fail to find the cache containing the installers, and the workflow will fail.
4. Deleting failed Workflow runs needs to be performed manually.
5. Deleting caches which will never be used again is recommended but documentation indicates that they will be purged when the total cache size reaches 10GB
6. Build artifacts are deleted after 2 days so if you need the build logs, be sure to download them.
7. To create a new hotfix, create a tag for build level zero of the new hotfix level and push it to origin

Example

If the latest level (tag) in the release candidate branch rc16790 is 1.6.7900.5 then the local commands would be
          git tag 1.6.7901.0
          git push --tags origin
Then push your hotfix commit on branch rc16790 to GitHub, and this will result in a build for the new code being initiated.