mirror of
https://github.com/dependabot/fetch-metadata.git
synced 2026-03-12 18:07:12 -04:00
dc2c459ae6
We're about to cut a new major version of this action,
and we don't anticipate any further releases of the `v1`
line.
So I simply updated the automation to float the `v2` tag.
Technically we could make it so it intelligently looks at
the release number and updates the appropriate tag, but
that'd be a bit more work and we don't need that complexity
in this repo right now given our very infrequent cadence of
bumping major versions.
As explained in a [code comment](f2f0ad1522/.github/workflows/release-move-tracking-tag.yml (L11-L28)):
```
# 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.
```
91 lines
4.3 KiB
YAML
91 lines
4.3 KiB
YAML
name: Release - Bump Version
|
|
|
|
on:
|
|
workflow_dispatch:
|
|
inputs:
|
|
version_type:
|
|
description: "Version Type?"
|
|
required: true
|
|
type: choice
|
|
options:
|
|
- major
|
|
- minor
|
|
- patch
|
|
default: "minor"
|
|
|
|
jobs:
|
|
Create-PR-To-Bump-Fetch-Metadata-Version:
|
|
runs-on: ubuntu-latest
|
|
|
|
steps:
|
|
- name: Generate token
|
|
id: generate_token
|
|
uses: actions/create-github-app-token@f2acddfb5195534d487896a656232b016a682f3c # v1.9.0
|
|
with:
|
|
app-id: ${{ secrets.FETCH_METADATA_ACTION_AUTOMATION_APP_ID }}
|
|
private-key: ${{ secrets.FETCH_METADATA_ACTION_AUTOMATION_PRIVATE_KEY }}
|
|
|
|
- uses: actions/checkout@v4
|
|
with:
|
|
# Ensure we start from main in case the workflow is run from a branch
|
|
ref: "main"
|
|
token: ${{ steps.generate_token.outputs.token }}
|
|
|
|
- uses: actions/setup-node@v4 # bin/bump-version needs npm
|
|
with:
|
|
node-version-file: .nvmrc
|
|
|
|
- name: Bump the version
|
|
# Currently we don't run via `schedule` trigger since this repo isn't active enough.
|
|
# However, if that ever changes, it will run with no inputs, so version_type will default to 'minor'
|
|
run: |
|
|
NEW_VERSION=$(bin/bump-version ${{ github.event.inputs.version_type || 'minor' }})
|
|
echo "New version is: $NEW_VERSION"
|
|
echo "NEW_VERSION=$NEW_VERSION" >> $GITHUB_ENV
|
|
|
|
- name: Configure the git user
|
|
run: |
|
|
git config user.name "github-actions[bot]"
|
|
# Specifying the full email allows the avatar to show up: https://github.com/orgs/community/discussions/26560
|
|
git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
|
|
|
|
- name: Create a branch and commit the changes
|
|
run: |
|
|
# Using an idempotent branch name ensures no duplicate PR's are created
|
|
# if the action is re-run before the previous PR is merged.
|
|
# The branch name is purposefully different from the release tag to
|
|
# avoid ambiguity when selecting git refs.
|
|
git checkout -b "bump-to-${{ env.NEW_VERSION }}"
|
|
git add package.json package-lock.json
|
|
echo "Creating commit / PR linking to the releases notes URL."
|
|
echo "This URL will 404 until the release is actually tagged, which you should do as soon as the PR is merged."
|
|
git commit -m "${{ env.NEW_VERSION }}" -m "Release notes: https://github.com/${{ github.repository }}/releases/tag/${{ env.NEW_VERSION }}"
|
|
|
|
- name: Push the branch
|
|
run: |
|
|
echo "Pushing branch to remote. If this fails, check if a branch/PR already exists for this version."
|
|
git config push.autoSetupRemote true
|
|
git push
|
|
|
|
- name: Create a PR from the branch with the commit
|
|
run: |
|
|
PR_URL=$(gh pr create --fill) # `fill` re-uses the title / body from the commit
|
|
echo "PR created at URL: $PR_URL"
|
|
echo "PR_URL=$PR_URL" >> $GITHUB_ENV
|
|
env:
|
|
GH_TOKEN: ${{ steps.generate_token.outputs.token }}
|
|
|
|
- name: Set summary
|
|
run: |
|
|
echo ":rocket: PR created at URL: ${{ env.PR_URL }}" >> $GITHUB_STEP_SUMMARY
|
|
echo "" >> $GITHUB_STEP_SUMMARY
|
|
echo "After the PR is approved/merged, create a new release tagged as \`${{ env.NEW_VERSION }}\`, _making sure to point it at the merge commit_:" >> $GITHUB_STEP_SUMMARY
|
|
echo "* You can do this via the web UI - use the \`Generate release notes\` button and then edit as needed: https://github.com/${{ github.repository }}/releases/new?tag=${{ env.NEW_VERSION }}&title=${{ env.NEW_VERSION }}" >> $GITHUB_STEP_SUMMARY
|
|
echo "* Or via the GitHub CLI:" >> $GITHUB_STEP_SUMMARY
|
|
echo "\`\`\`" >> $GITHUB_STEP_SUMMARY
|
|
echo " gh release create ${{ env.NEW_VERSION }} --title ${{ env.NEW_VERSION }} --generate-notes --draft" >> $GITHUB_STEP_SUMMARY
|
|
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, another GitHub Action workflow automatically moves the floating \`v2\` tag to point at this release." >> $GITHUB_STEP_SUMMARY
|