Release Process

Steps that should be taken when preparing for and executing a release.

Preparation

  1. Merge all PRs that should be included in the release.

  2. Open a draft PR. This should have master as the source and release as the target. The PR should be labeled as release.

  3. Integration tests should be triggered automatically by opening the PR. Wait for the tests to complete before continuing.

Important

Only one instance of each test should be run at a time. Either cancel any running test or wait for them to finish before committing/merging anything new to master which will trigger a new instance of each test to begin.

  1. Fix any failing integration tests.

  2. Close the PR.

  3. Fetch updates for all branches of the onicagroup/runway remote. (e.g. git fetch --all)

  4. Checkout the master branch from the onicagroup/runway remote. This is to ensure your local master branch matches the correct remote. (e.g. git checkout -b master --track <remote>/master)

  5. Apply a version bump where necessary (CHANGELOG.md, etc)

  6. Commit any changes to master.

  7. Push the commits to the onicagroup/runway remote. (e.g. git push <remote> master)

Execution

  1. Fetch updates for all branches of the onicagroup/runway remote. (e.g. git fetch --all)

  2. Checkout the master branch from the onicagroup/runway remote. This is to ensure your local master branch matches the correct remote. (e.g. git checkout -b master --track <remote>/master)

  3. Checkout the release branch from the onicagroup/runway remote. (e.g. git checkout -b release --track <remote>/release)

  4. Execute git merge --ff-only master to fast forward the branch.

  5. Push the changes to the onicagroup/runway remote. (e.g. git push <remote> release)

  6. Create a tag on the release branch for the new version. This can be done one of two ways:

  • Navigate to the Releases section of the repository on GitHub. The should be a Draft Release already started that was automatically generated from PRs that were merged since the last release. Editing the draft will give provide the option to create a new tag for the release.

  • Create a signed tag on the release branch for the new version and push it to the onicagroup/runway remote

git tag --sign v0.0.0
git push <remote> v0.0.0
  1. Navigate to the Releases section of the repository on GitHub and edit the Draft Release if you have not done so already.

  2. Rename the release to match the version tag and associate it with the tag that was just created.

  3. Edit the description of the release as needed but, there should be little to no changes required if all PRs were properly labeled.

  4. Mark the release as a pre-release if applicable (alpha, beta, release candidate, etc).

  5. Publish the release on GitHub.

At this point, GitHub Action will begin building the deployment packages & automatically publishing them to npm, PyPi, and AWS S3. The Publish Release workflow can be monitored for progress.

After all the publishing steps have completed:

  1. Download the following artifacts from the Publish Release workflow:

  • npm-pack

  • pyinstaller-onefile-macos-latest

  • pyinstaller-onefile-ubuntu-latest

  • pyinstaller-onefile-windows-latest

  • pypi-dist

  1. Attach all artifacts to the release that were previously downloaded.