From a2a3a43b4aacd26a656ce1cbf5adcb7c12acda1e Mon Sep 17 00:00:00 2001 From: Jeff Widman Date: Fri, 19 May 2023 08:37:20 -0700 Subject: [PATCH] Add workflow for floating the `v1` tag to the latest release (#361) This adds a workflow for floating the `v1` tag to the latest release. This way we reduce the chance of someone fat-fingering the necessary `git` commands. --- .github/workflows/release-bump-version.yml | 2 +- .../workflows/release-move-tracking-tag.yml | 43 +++++++++++++++++++ README.md | 8 +--- 3 files changed, 45 insertions(+), 8 deletions(-) create mode 100644 .github/workflows/release-move-tracking-tag.yml diff --git a/.github/workflows/release-bump-version.yml b/.github/workflows/release-bump-version.yml index 48b9eff..1fc9a2e 100644 --- a/.github/workflows/release-bump-version.yml +++ b/.github/workflows/release-bump-version.yml @@ -80,4 +80,4 @@ jobs: echo " > https://github.com/${{ github.repository }}/releases/tag/untagged-XXXXXX" >> $GITHUB_STEP_SUMMARY echo " # Use the generated URL to review/edit the release notes." >> $GITHUB_STEP_SUMMARY echo "\`\`\`" >> $GITHUB_STEP_SUMMARY - echo "Once the release is tagged, move the floating \`v1\` tag to point at this release." >> $GITHUB_STEP_SUMMARY + echo "Once the release is tagged, another GitHub Action workflow automatically moves the floating \`v1\` tag to point at this release." >> $GITHUB_STEP_SUMMARY diff --git a/.github/workflows/release-move-tracking-tag.yml b/.github/workflows/release-move-tracking-tag.yml new file mode 100644 index 0000000..610615a --- /dev/null +++ b/.github/workflows/release-move-tracking-tag.yml @@ -0,0 +1,43 @@ +name: Release - Move Tracking Tag + +on: + release: + types: [published] + +jobs: + Move-Tracking-Tag-To-Latest-Release: + runs-on: ubuntu-latest + + # We have a choice - defensiveness vs convenience: + # 1. Be defensive by filtering if the release doesn't look like a normal + # version, or if it's a patch release to an older version... the logic + # gets tricky quickly. Easiest way to be 100% sure is stop running this + # on `release` and instead require a human to manually run this workflow + # after they tag a release. + # 2. Minimize the upfront hassle by assuming every release is a normal + # version release and the latest one. Today both are resoundingly true + # as this repo isn't that active/busy, so we don't worry about + # multiple release branches, pre-releases, etc. + # + # For now I've gone with option 2, as it is much more convenient and if we + # typo something during a release it's easy to fix by immediately tagging a + # correct release. And if we don't notice the typo, well, in that case + # requiring a human to manually run the workflow wouldn't have protected us + # either, we'd have had to filter by only things that look like versions. + # Anyway, for now this is good enough, and if it gets to be a problem down + # the road we increase the robustness of this. + + steps: + - uses: actions/checkout@v3 + with: + token: ${{ secrets.DEPENDABOT_AUTOMATION_PAT }} + + - name: Move the tracking tag + run: git tag -f v1 + + - name: Push the new tag value back to the repo + run: git push -f origin refs/tags/v1 + + - name: Set summary + run: | + echo ":rocket: Successfully moved the \`v1\` tag to point at release: ${{ github.event.release.name }} with SHA: \`$GITHUB_SHA\`." >> $GITHUB_STEP_SUMMARY diff --git a/README.md b/README.md index ff37105..b253dc7 100644 --- a/README.md +++ b/README.md @@ -200,13 +200,7 @@ jobs: 1. Run the action to generate a version bump PR. 2. Merge the PR. 3. Tag that merge commit as a new release using the format `v1.2.3`. The job summary contains a URL pre-populated with the correct version for the title and tag. - 4. Update the `v1` tracking tag to point to the new version - ```bash - git fetch --all --tags - git checkout v1.x.x # Check out the release tag - git tag -f v1 # Force update the tracking tag - git push -f --tags - ``` + 4. Once the release is tagged, another GitHub Action workflow automatically moves the `v1` tracking tag to point to the new version.