Skip to content

Support creating release branches when releasing new versions #1627

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Mar 12, 2025
Merged

Support creating release branches when releasing new versions #1627

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
63239c7
Support creating release branches when releasing new versions
alcaeus Mar 3, 2025
90f9a30
Use same logic as in laravel integration
alcaeus Mar 3, 2025
69c381e
Update .github/workflows/release.yml
alcaeus Mar 3, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 24 additions & 3 deletions .github/workflows/release.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -57,7 +57,9 @@ jobs:
- name: "Store version numbers in env variables"
run: |
echo RELEASE_VERSION=${{ inputs.version }} >> $GITHUB_ENV
echo RELEASE_VERSION_WITHOUT_STABILITY=$(echo ${{ inputs.version }} | awk -F- '{print $1}') >> $GITHUB_ENV
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is necessary as we need to check for a patch release. The best way is to cut the suffix (e.g. -RC0) from the version and only keep the major, minor, and patch numbers.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Noted that this is using the -F sepstring syntax from awk(1p). It wasn't immediately clear to me due to the omitted space, but https://askubuntu.com/a/342850 helped clarify.

echo RELEASE_BRANCH=v$(echo ${{ inputs.version }} | cut -d '.' -f-2) >> $GITHUB_ENV
echo DEVELOPMENT_BRANCH=v$(echo ${{ inputs.version }} | cut -d '.' -f-1).x >> $GITHUB_ENV

- name: "Ensure release tag does not already exist"
run: |
Expand All @@ -66,16 +68,35 @@ jobs:
exit 1
fi

- name: "Fail if branch names don't match"
if: ${{ github.ref_name != env.RELEASE_BRANCH }}
# For patch releases (A.B.C where C != 0), we expect the release to be
# triggered from the vA.B release branch
- name: "Fail if patch release is created from wrong release branch"
if: ${{ !endsWith(env.RELEASE_VERSION_WITHOUT_STABILITY, '.0') && env.RELEASE_BRANCH != github.ref_name }}
run: |
echo '❌ Release failed due to branch mismatch: expected ${{ inputs.version }} to be released from ${{ env.RELEASE_BRANCH }}, got ${{ github.ref_name }}' >> $GITHUB_STEP_SUMMARY
exit 1

# For non-patch releases (A.B.C where C == 0), we expect the release to
# be triggered from the vA.x development branch or the vA.B release branch.
# This includes pre-releases (e.g. alpha, beta, rc)
- name: "Fail if non-patch release is created from wrong release branch"
if: ${{ endsWith(env.RELEASE_VERSION_WITHOUT_STABILITY, '.0') && env.RELEASE_BRANCH != github.ref_name && env.DEVELOPMENT_BRANCH != github.ref_name }}
run: |
echo '❌ Release failed due to branch mismatch: expected ${{ inputs.version }} to be released from ${{ env.RELEASE_BRANCH }} or ${{ env.DEVELOPMENT_BRANCH }}, got ${{ github.ref_name }}' >> $GITHUB_STEP_SUMMARY
exit 1

#
# Preliminary checks done - commence the release process
#

# Create the new release branch if we're releasing from the vA.x
# development branch
- name: "Create new release branch"
if: ${{ github.ref_name != env.RELEASE_BRANCH }}
run: |
git checkout -b ${{ env.RELEASE_BRANCH }}
git push origin ${{ env.RELEASE_BRANCH }}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For reproducibility, if the branch already exists (because the job has already been launched but failed when calling the GitHub API, for example), then the git push will fail.
We can accept this and consider deleting the branch manually in this case. Or you can check whether the branch exists and is up-to-date.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point.

What we can do is that we check out all branches (similar to the merge-up workflow) and switch to that branch in certain instances. Those can be releasing a non-patch release from the development branch when the release branch already exists instead of creating the new branch. The only issue with that is that instead of using the release workflow from that branch, it runs the release workflow from whatever branch was used. This shouldn't be a big issue in most cases, but it's important to keep in mind.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Turns out, we're already using this kind of logic in the Laravel integration: https://github.com/mongodb/laravel-mongodb/blob/e373350f436596402a2b51cd7a8fe68fdd2df848/.github/workflows/release.yml#L44-L67

With that in mind, I'd update the logic here to be the same as in the Laravel integration, and improve on that in a separate step. We can also consider extracting the logic to drivers-github-tools, which already holds some driver-specific actions.


- name: "Set up drivers-github-tools"
uses: mongodb-labs/drivers-github-tools/setup@v2
with:
Expand All @@ -90,7 +111,7 @@ jobs:
EOL

- name: "Create draft release"
run: echo "RELEASE_URL=$(gh release create ${{ inputs.version }} --target ${{ github.ref_name }} --title "${{ inputs.version }}" --notes-file release-message --draft)" >> "$GITHUB_ENV"
run: echo "RELEASE_URL=$(gh release create ${{ inputs.version }} --target ${{ env.RELEASE_BRANCH }} --title "${{ inputs.version }}" --notes-file release-message --draft)" >> "$GITHUB_ENV"
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using the (potentially newly created) release branch ensures that GitHub shows the correct "x commits to " when looking at a release on GitHub.


- name: "Create release tag"
uses: mongodb-labs/drivers-github-tools/tag-version@v2
Expand Down
Loading