-
Notifications
You must be signed in to change notification settings - Fork 79
About the automated release process
Note The release process is intended to be atomic. Once the release process is initiated on a particular commit, it should either run to completion on that commit, or roll back to the pre-release state. No one should make changes in the autorelease branch, it is to be used by the release automation bot only. If any last-minute issues are discovered during the release process, stop, roll back, fix the issue through our routine development process, and then restart the release over from the beginning.
-
Initiate the release by manually triggering the "Release (Part 1 of 2)" Github Action:
- Navigate to the Actions tab
- Select "Release (Part 1 of 2)" in the sidebar
- Click the "Run workflow" dropdown
- Leave the "Use workflow from" dropdown set to the
main
branch - In the
version
box, enter the version to be released - Click "Run workflow"
- Wait for the workflow to succeed. If the workflow fails for any reason, it will automatically roll back. Fix any problems and then re-initiate the release.
-
Navigate to the release PR created by the release workflow. This is the final checkpoint for human review of the release. Follow the instructions in the PR comment:
- Make sure that the automated changes look correct
- Wait for BOTH the PR checks AND the tag checks to complete
- Test the workbench. The release should be tested by at least 2 people and on both Mac and Windows:
- Download the workbench
- Install the build and all sample data
- Try running a few models and interacting with anything that changed in this release.
If there is a bug, decline the PR. Follow the usual bugfix process (create an issue, submit a fix in a separate PR into
main
, request review). Once the fix has been merged, restart the release process from the beginning. If either workflow fails due to an intermittent problem, rerun it through the GitHub UI. Proceed to approve and merge the PR once it succeeds. -
When everything looks good, approve and merge the release PR. This will trigger the "Release (Part 2 of 2)" Github Action, which publishes the release on Github and PyPI.
-
Verify that the PyPI release and Github release look correct. The PyPI release should contain:
- One wheel for each combination of supported python version and operating system
- One sdist tar archive
The Github release should contain the above, plus:
- InVEST sample data zip archive
- InVEST User's Guide zip archive
- InVEST Workbench - Windows
- InVEST Workbench - Mac
- Source code zip archive (automatically added by Github)
- Source code tar archive (automatically added by Github)