Releases
Releasing a new version of Dex can be done by one of the core maintainers with push access to the git repository. It’s usually good to have an extra pair of eyes ready when tagging a new release though, so feel free to ask a peer to be ready in case anything goes wrong or you need a review.
The release process is semi-automated at the moment: artifacts are automatically built and published to GitHub Container Registry (primary source of container images) and Docker Hub.
The GitHub release needs to be manually created (use past releases as templates).
Note: this will hopefully be improved in the future.
Tagging a new release
Make sure you’ve uploaded your GPG keyand configured git to use that signing keyeither globally or for the Dex repo. Note that the email the key is issued for must be the email you use for git.
git config [--global] user.signingkey "{{ GPG key ID }}"
git config [--global] user.email "{{ Email associated with key }}"
Create a signed tag at the commit you wish to release.
RELEASE_VERSION=v2.0.0
git tag -s -m "Release $RELEASE_VERSION" $RELEASE_VERSION # optionally: commit hash as the last argument
Push that tag to the Dex repo.
git push origin $RELEASE_VERSION
Draft releases on GitHub and summarize the changes since the last release. See previous releasesfor the expected format.
Patch releases
Occasionally, patch releases might be necessary to fix an urgent bug or vulnerability.
First, check if there is a release branch for a minor release. Create one if necessary:
MINOR_RELEASE="v2.1.0"
RELEASE_BRANCH="v2.1.x"
git checkout -b $RELEASE_BRANCH tags/$MINOR_RELEASE
git push origin $RELEASE_BRANCH
If a patch version is needed (2.1.1, 2.1.2, etc.), checkout the desired release branch and cherry pick specific commits.
RELEASE_BRANCH="v2.1.x"
git checkout $RELEASE_BRANCH
git checkout -b "cherry-picked-change"
git cherry-pick (SHA of change)
git push origin "cherry-picked-change"
Open a PR onto $RELEASE_BRANCH
to get the changes approved.
Continue with the regular release process.