Skip to content

Commit

Permalink
Add workflow for creating release PR's
Browse files Browse the repository at this point in the history
Add a workflow for creating release PR's. This way we don't have to do
it locally, and we guarantee the `npm` version used to generate the
version bump is consistent and stays in-sync with the repo instead of
whatever the dev happened to have on their local computer.
  • Loading branch information
jeffwidman committed May 18, 2023
1 parent ec762dd commit 0cbbe35
Show file tree
Hide file tree
Showing 3 changed files with 110 additions and 44 deletions.
87 changes: 87 additions & 0 deletions .github/workflows/release-bump-version.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,87 @@
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:
- uses: actions/checkout@v3
with:
# Ensure we start from main in case the workflow is run from a branch
ref: "main"
token: ${{ secrets.DEPENDABOT_AUTOMATION_PAT }}

- name: Read .nvmrc
id: nvm
run: echo ::set-output name=NVMRC::$(cat .nvmrc)

- uses: actions/setup-node@v3 # bin/bump-version needs npm
with:
node-version: ${{ steps.nvm.outputs.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: ${{ secrets.DEPENDABOT_AUTOMATION_PAT }}

- 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, move the floating \`v1\` tag to point at this release." >> $GITHUB_STEP_SUMMARY
35 changes: 16 additions & 19 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -186,30 +186,27 @@ jobs:
<details><summary>:book: Release guide</summary>
<p>

- Dependabot PR's:
- We expect Dependabot PRs to be passing CI and have any changes to the `dist/` folder built for production dependencies
- Some development dependencies may fail the `dist/` check if they modify the Typescript compilation, these should be updated manually via `npm run build`. See the [`dependabot-build`](https://github.com/dependabot/fetch-metadata/blob/main/.github/workflows/dependabot-build.yml) action for details.
- Checkout and update `main`, then use the `bin/bump-version` script to create a release PR
```bash
git checkout main
git pull
bin/bump-version -p patch # patch | minor | major
```
- Merge the PR after getting it reviewed
- Create a new release tagged as `v1.X.X` format:
- Either via the web UI: https://github.com/dependabot/fetch-metadata/releases/new
- Or via the CLI:
```bash
gh release create v1.X.X --generate-notes --draft
> https://github.com/dependabot/fetch-metadata/releases/tag/untagged-XXXXXX
# Use the generated URL to review/edit the release notes, and then publish it.
```
- Update the `v1` tracking tag to point to the new version
## Dependabot PR's

- We expect Dependabot PRs to be passing CI and have any changes to the `dist/` folder built for production dependencies
- Some development dependencies may fail the `dist/` check if they modify the Typescript compilation, these should be updated manually via `npm run build`. See the [`dependabot-build`](https://github.com/dependabot/fetch-metadata/blob/main/.github/workflows/dependabot-build.yml) action for details.

## Tagging a new release

Publish a new release by running the [`Release - Bump Version`](https://github.com/dependabot/fetch-metadata/actions/workflows/release-bump-version.yml) workflow and following the instructions on the job summary.

In a nutshell the process will be:

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
```

</p>
</details>
32 changes: 7 additions & 25 deletions bin/bump-version
Original file line number Diff line number Diff line change
@@ -1,31 +1,13 @@
#!/bin/bash

usage() { echo "Usage: $0 -p [major | minor | patch]" 1>&2; exit 1; }
usage() { echo "Usage: $0 major|minor|patch" 1>&2; exit 1; }

while getopts "p:" o; do
case "${o}" in
p)
patch_level=${OPTARG}
(( patch_level == 'major' || patch_level == 'minor' || patch_level == 'patch'))
;;
*)
usage
;;
esac
done
version_bump_type=$1

echo "$patch_level"

if [[ -z "${patch_level}" ]]; then
if [ "$version_bump_type" == "major" ] || [ "$version_bump_type" == "minor" ] || [ "$version_bump_type" == "patch" ]; then
# TODO catch if `npm version` returns non-zero exit code
new_version=$(npm version "$version_bump_type" --no-git-tag-version)
echo "$new_version"
else
usage
fi

new_version=$(npm version "${patch_level}" --no-git-tag-version)
git checkout -b "${new_version}"-release-notes
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 "${new_version}" -m "Release notes: https://github.com/dependabot/fetch-metadata/releases/tag/v${new_version}"
gh pr create --fill # `fill` re-uses the title / body from the commit
echo "PR created for ${new_version}"

0 comments on commit 0cbbe35

Please sign in to comment.