Add handle-release-branches-workflow

[kylegach]

Why

To trigger branch-based versioned docs builds, we need to do some branch management between this repo and frontpage. By automating the creation of the release-x-x branches (both here and in frontpage), we can develop as usual, without having to manually ensure that the release-x-x branches are kept in-sync with main & next (here) and master (frontpage).

What I did

Scenarios

For each of the scenarios below, assume:

• "latest" (master branch) version is 6.3
• "next" (next branch) version is 6.4

On push to main

• Use webhook to kick off production frontpage deploy

On push to next

• Creates & force-pushes release-6-4 branch
• Sends dispatch event to frontpage repo to create release-6-4 branch

On push to release-x-x

• If pushing to release-6-4
  • Warns that changes will be lost on next push to next
  • 
  • 
• Else
  • Sends dispatch event to frontpage repo to create release-x-x branch
  • 

Questions

• Should this PR be against main?
• I think this workflow would obviate the need for the build-frontpage script. Is that correct?
  • If not, that script or this workflow will likely need modified to live alongside one another
• Have I done enough to safeguard this workflow?
• Is there a better way to alert of potentially lost changes than a failure w/ logged warning?
  • PR comment, perhaps?
• Sending the dispatch event to frontpage will require an access token. I'm unsure what that should be. Do we have a bot account for such things?

[nx-cloud]

Nx Cloud Report

CI ran the following commands for commit 0308885. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this branch

Status	Command
	nx run-many --target=prepare --all --parallel --max-parallel=15

---

Sent with 💌 from NxCloud.

[kylegach]

This technique is from:

• https://blog.marcnuri.com/triggering-github-actions-across-different-repositories
• https://docs.github.com/en/rest/reference/repos#create-a-repository-dispatch-event

The frontpage workflow would look like:

name: Respond to request-create-frontpage-branch

on: [repository_dispatch]

jobs:
  build:
    runs-on: ubuntu-latest
    if: github.event.action == 'request-create-frontpage-branch'
    steps:
      - uses: actions/checkout@v2
      - run: |
          echo "Creating `${{ github.event.client_payload.branch }}` branch..."
          git branch temp
          git push -f origin temp:${{ github.event.client_payload.branch }}
          curl -X POST https://api.github.com/repos/kylegach/actions-test-a/dispatches \
          -H 'Accept: application/vnd.github.v3+json' \
          -u ${{ secrets.ACCESS_TOKEN }} \
          --data '{"event_type": "created-frontpage-branch", "client_payload": { "branch": "${{ needs.branch-checks.outputs.branch }}" }}'

Pushing the release-x-x branch would then kick off a Netlify build for that branch, which would pull in the appropriate version's content from this repo's release-x-x branch.

The curl above would allow for this repo to receive a confirmation message, if desired. Otherwise, it can be removed.

[shilman]

Should this PR be against main?

No, next is the default branch

I think this workflow would obviate the need for the build-frontpage script. Is that correct?
If not, that script or this workflow will likely need modified to live alongside one another

Yes, I believe so

Have I done enough to safeguard this workflow? Is there a better way to alert of potentially lost changes than a failure w/ logged warning? Which steps could fail?

At any rate, since this is only copying the branch automatically, we never lose information correct? We only run the risk of some info not propagating properly

Sending the dispatch event to frontpage will require an access token. I'm unsure what that should be. Do we have a bot account for such things?

Yes we do -- DM'ing

[kylegach]

Why temp.xxx?

Because the value of ${{ needs.get-next-release-branch.outputs.branch }}, e.g. release-6-4 is likely to already exist, and this was easier and more straightforward (imo) than finding a way around the error when creating a branch that already exists.

[shilman]

@kylegach is the frontpage side set up to read temp:xxx branches? or am i misunderstanding

[kylegach]

@kylegach is the frontpage side set up to read temp:xxx branches? or am i misunderstanding

That's a syntax to push the local temp branch to (something like) release-6-4 on the remote.

More info: https://stackoverflow.com/a/28302850

[kylegach]

since this is only copying the branch automatically, we never lose information correct? We only run the risk of some info not propagating properly

Realized I never answered this. 🤦‍♂️ To explain, I'll keep the same assumptions from the description: "latest" = 6.3 and "next" = 6.4. This workflow has one potentially dangerous outcome: push to next creates release-6-4, which is then force-pushed over whatever release-6-4 may be on remote. So I'm fairly sure the only data loss would be from someone pushing to release-6-4 directly, which this workflow explicitly no-ops and warns about (via a failure and a log message).

[kylegach]

I don't believe the failing CircleCi checks, which are both e2e tests, are related.

[shilman]

Amazing job @kylegach !!! 🚀