create-release-branch #32
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
name: create-release-branch | |
on: | |
workflow_dispatch: | |
inputs: | |
# When the workflow is executed manually, the user can select whether the branch should correspond to a major, | |
# minor, or patch release. | |
release-type: | |
type: choice | |
description: what kind of release? | |
options: | |
- major | |
- minor | |
- patch | |
required: true | |
schedule: | |
# Cron syntax is "minute[0-59] hour[0-23] date[1-31] month[1-12] day[0-6]". '*' is 'any value,' and multiple values | |
# can be specified with comma-separated lists. All times are UTC. | |
# So this expression means "run at 12 PM UTC, every Friday". | |
- cron: "0 12 * * 5" | |
jobs: | |
# Depending on circumstances, we may want to exit early instead of running the workflow to completion. | |
verify-should-run: | |
runs-on: macos-latest | |
outputs: | |
should-run: ${{ steps.main.outputs.should_run }} | |
steps: | |
- id: main | |
run: | | |
# If the workflow was manually triggered, then it should always be allowed to run to completion. | |
[[ "${{ github.event_name }}" = "workflow_dispatch" ]] && echo "should_run=true" >> "$GITHUB_OUTPUT" && exit 0 | |
# `date -u` returns UTC datetime, and `%u` formats the output to be the day of the week, with 1 being Monday, | |
# 2 being Tuesday, etc. | |
TODAY_DOW=$(date -u +%u) | |
# This `date` expression returns the last Tuesday of the month, which is our Release Day. %d formats the output | |
# as the day of the month (1-31). | |
NEXT_RELEASE_DATE=$(date -u -v1d -v+1m -v-1d -v-tue +%d) | |
# This `date` expression returns next Tuesday, and `%d` formats the output as the day of the month (1-31). | |
NEXT_TUESDAY_DATE=$(date -u -v+tue +%d) | |
# If the workflow wasn't manually triggered, then it should only be allowed to run to completion on the Friday | |
# before Release Day. | |
[[ $TODAY_DOW != 5 || $NEXT_RELEASE_DATE != $NEXT_TUESDAY_DATE ]] && echo "should_run=false" >> "$GITHUB_OUTPUT" || echo "should_run=true" >> "$GITHUB_OUTPUT" | |
create-release-branch: | |
runs-on: macos-latest | |
needs: verify-should-run | |
if: ${{ needs.verify-should-run.outputs.should-run == 'true' }} | |
env: | |
GH_TOKEN: ${{ github.token }} | |
permissions: | |
contents: write | |
outputs: | |
branch-name: ${{ steps.create-branch.outputs.branch_name }} | |
steps: | |
# Checkout `dev` | |
- uses: actions/checkout@v4 | |
with: | |
ref: 'dev' | |
# We need to set up Node and install our Node dependencies. | |
- uses: actions/setup-node@v4 | |
with: | |
node-version: 'lts/*' # Always use Node LTS for building dependencies. | |
- run: yarn | |
# Increment the version as desired locally, without actually committing anything. | |
- name: Locally increment version | |
run: | | |
# A workflow dispatch event lets the user specify what release type they want. | |
if [[ "${{ github.event_name }}" = "workflow_dispatch" ]]; then | |
RELEASE_TYPE=${{ github.event.inputs.release-type }} | |
# The regularly scheduled releases are always minor. | |
else | |
RELEASE_TYPE=minor | |
fi | |
# Increment the version as needed | |
npm --no-git-tag-version version $RELEASE_TYPE | |
# The branch protection rule for `release-x.y.z` branches prevents pushing commits directly. To work around this, | |
# we create an interim branch that we _can_ push commits to, and we'll do our version bookkeeping in that branch | |
# instead. | |
- id: create-interim-branch | |
run: | | |
NEW_VERSION=$(jq -r ".version" package.json) | |
INTERIM_BRANCH_NAME=${NEW_VERSION}-interim | |
# Create and check out the interim branch. | |
git checkout -b $INTERIM_BRANCH_NAME | |
# Immediately push the interim branch with no changes, so GraphQL can push to it later. | |
git push --set-upstream origin $INTERIM_BRANCH_NAME | |
# Update our dependencies | |
- run: yarn upgrade | |
# Use the GraphQL API to create a signed commmit with our changes. | |
- run: | | |
# GraphQL needs to know what branch to push to. | |
BRANCH=$(git rev-parse --abbrev-ref HEAD) | |
# GraphQL needs a message for the commit. | |
NEW_VERSION=$(jq -r ".version" package.json) | |
MESSAGE="Preparing for v$NEW_VERSION release." | |
# GraphQL needs the latest versions of the files we changed, as Base64 encoded strings. | |
NEW_PACKAGE="$(cat package.json | base64)" | |
NEW_YARN_LOCK="$(cat yarn.lock | base64)" | |
gh api graphql -F message="$MESSAGE" -F oldOid=`git rev-parse HEAD` -F branch="$BRANCH" \ | |
-F newPackage="$NEW_PACKAGE" -F newYarnLock="$NEW_YARN_LOCK" \ | |
-f query=' | |
mutation ($message: String!, $oldOid: GitObjectID!, $branch: String!, $newPackage: Base64String!, $newYarnLock: Base64String!) { | |
createCommitOnBranch(input: { | |
branch: { | |
repositoryNameWithOwner: "forcedotcom/sfdx-code-analyzer-vscode", | |
branchName: $branch | |
}, | |
message: { | |
headline: $message | |
}, | |
fileChanges: { | |
additions: [ | |
{ | |
path: "package.json", | |
contents: $newPackage | |
}, { | |
path: "yarn.lock", | |
contents: $newYarnLock | |
} | |
] | |
}, | |
expectedHeadOid: $oldOid | |
}) { | |
commit { | |
id | |
} | |
} | |
}' | |
# Now that we've done our bookkeeping commits on the interim branch, use it as the base for the real release branch. | |
- name: Create release branch | |
id: create-branch | |
run: | | |
# The commit happened on the remote end, not ours, so we need to clean the directory and pull. | |
git checkout -- . | |
git pull | |
# Now we can create the actual release branch. | |
NEW_VERSION=$(jq -r ".version" package.json) | |
git checkout -b release-$NEW_VERSION | |
git push --set-upstream origin release-$NEW_VERSION | |
# Now that we're done with the interim branch, delete it. | |
git push -d origin ${NEW_VERSION}-interim | |
# Output the release branch name so we can use it in later jobs. | |
echo "branch_name=release-$NEW_VERSION" >> "$GITHUB_OUTPUT" | |
# Build the scanner tarball so it can be installed locally when we run tests. | |
build-scanner-tarball: | |
name: 'Build scanner tarball' | |
needs: verify-should-run | |
uses: ./.github/workflows/build-scanner-tarball.yml | |
with: | |
# Note: Using `dev` here is technically incorrect. For full completeness's sake, we should probably be | |
# using the branch corresponding to the upcoming scanner release. However, identifying that branch is | |
# non-trivial, and there are unlikely to be major differences between the two that appear in the few days | |
# between creating the branch and releasing it, so it _should_ be fine. | |
target-branch: 'dev' | |
# Run all the various tests against the newly created branch. | |
test-release-branch: | |
name: 'Run unit tests' | |
needs: [build-scanner-tarball, create-release-branch] | |
uses: ./.github/workflows/run-tests.yml | |
with: | |
# We want to validate the extension against whatever version of the scanner we *plan* to publish, | |
# not what's *already* published. | |
use-scanner-tarball: true | |
target-branch: ${{ needs.create-release-branch.outputs.branch-name }} |