Skip to content

About the automated release process

Dave Fisher edited this page Dec 19, 2024 · 3 revisions

Running 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.

Release process flow chart

  • 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)