Skip to content

Latest commit

 

History

History
180 lines (130 loc) · 7.4 KB

RELEASING.md

File metadata and controls

180 lines (130 loc) · 7.4 KB
Raw

Releasing

Releases of globus-compute-sdk and globus-compute-endpoint are always done with a single version number, even when only one package has changes.

The process is partially automated with tools to help along the way.

Prerequisites

You must have the following tools installed and available:

  • git
  • scriv
  • tox

You will also need the following credentials:

  • a configured GPG key in git in order to create signed tags
  • pypi credentials for use with twine (e.g. a token in ~/.pypirc) valid for publishing globus-compute-sdk and globus-compute-endpoint

Alpha releases

  1. Branch off from the main branch to create a release branch (e.g., v.1.1.0):
git checkout -b v1.1.0 main
  1. Bump the version of both packages to a new alpha release (e.g., 1.0.0 -> 1.1.0a0):
$EDITOR compute_sdk/globus_compute_sdk/version.py compute_endpoint/setup.py compute_endpoint/globus_compute_endpoint/version.py
  1. Commit the changes:
git add compute_sdk/globus_compute_sdk/version.py compute_endpoint/setup.py compute_endpoint/globus_compute_endpoint/version.py
git commit -m "Bump versions for alpha release v1.1.0a0"
git push -u origin v1.1.0
  1. Run ./release.sh from the repo root. This script creates a signed tag named after the current version and pushes it to GitHub, then uses the tox release command to push each package to PyPi.

Alpha release bugfixes

  1. Branch off from the release branch to create a new bugfix branch:
git checkout -b some-bugfix v1.1.0
  1. Commit your changes and push to GitHub.
git add .
git commit -m "Fixed X"
git push -u origin some-bugfix

  1. Open a PR in GitHub to merge the bugfix branch into the release branch.

  2. Once the PR is approved and merged, pull the new commits from the remote release branch:

git checkout v1.1.0
git pull
  1. Repeat steps 2 through 4 of the main Alpha releases procedure. Be sure to only bump the alpha version number (e.g., 1.1.0a0 -> 1.1.0a1).

Production releases

  1. Checkout the release branch.
git checkout v1.1.0
  1. Remove the alpha version designation for both packages (e.g., 1.1.0a1 -> 1.1.0):
$EDITOR compute_sdk/globus_compute_sdk/version.py compute_endpoint/setup.py compute_endpoint/globus_compute_endpoint/version.py
  1. Update the changelog:
scriv collect --edit
  1. Commit the changes:
git add changelog.d/ docs/changelog.rst
git add compute_sdk/globus_compute_sdk/version.py compute_endpoint/setup.py compute_endpoint/globus_compute_endpoint/version.py
git commit -m "Bump versions and changelog for release v1.1.0"
git push

  1. Run ./release.sh from the repo root.

  2. Open a PR in GitHub to merge the release branch into main.

    ⚠️ Important: Once approved, merge the PR using the "Merge commit" option. This will ensure that the tagged commits and bug fixes from the release branch are properly added to the main branch.

  3. Create a GitHub release from the tag. See GitHub documentation for instructions.

DEB/RPM Packaging Workflow

Pre-requisites

Before building the packages:

  • ensure that the release itself, either the alpha or prod versions, is published on PyPI.
  • VPN is enabled to access the build page.

Build Process

To build the alpha DEB/RPM packages after the alpha PyPI is released, simply put the tag name ie. v2.29.0a0 or v2.29.0 into the input textbox of the build page here. then clicking the green Build button.

For production builds, check the BUILD_FOR_STABLE box.

  1. Notes Our alpha builds will go to the unstable repo, and production packages goes to both the testing and stable repos.

    After this build process for production, the testing and stable packages will reside in an internal globus 'holding' repo. GCS manages the infrastructure so we need to run another Jenkins build to push it to live if GCS is not having a release the same week. TBD details

  2. (Access on VPN) Click the build button here

  3. Wait 20-30 minutes and confirm that the build is green

  4. For production release cycles where there is also a GCS release, if we push our packages before they do, skip the following (also not necessary for alpha releases)

Old Build Instructions

(Previously) As a temporary workaround, we needed to add a few lines to manually set some env variables in our JenkinsFile before triggering the build, as detailed below.

  1. Notes
  2. (Access on VPN) Click the build button here
  3. Wait 20-30 minutes and confirm that the build is green
  4. For production release, we will have finished the build before the GCS team, and can notify them that our build is complete. They then will publish all packages when they finish their builds, which includes ours.