[No QA] Move version-bump and automerge code to its own workflow #2329

roryabraham · 2021-04-09T23:28:25Z

Details

This pull request does a few things:

At an abstract level, it establishes a pattern by which we can make a "utility workflow" or "subroutine", which can be synchronously or asynchronously executed by another workflow. Nifty! Here's how it works:
- Make the utility workflow execute on the workflow_dispatch event. That means that the workflow can be manually triggered via an arbitrary workflow_dispatch event.
- Use https://github.com/convictional/trigger-workflow-and-wait to trigger the specified workflow with the provided inputs and wait until that workflow completes. Alternatively, you can choose not to wait (we don't do that anywhere in this PR).
  - GitHub Actions are designed such that, by default, events triggered by one workflow cannot cause another to execute. This is by design to prevent circular workflows (infinite loops). However, we can work around this by using the OS_BOTIFY_TOKEN instead of the default GITHUB_TOKEN.

Ultimately, this should promote code reuse and greatly simplify the handling of race conditions, the creation of new workflows, and the update of branches.

Now, specifically what this PR does:

Creates a new workflow called `createNewVersion` that:

Creates a new version with a specified SEMVER_LEVEL
Creates a version-bump pull request against main to update the app version.
Approves and automatically merges that pull request.

It's important to note that the createNewVersion workflow uses softprops/turnstyle to ensure that only one instance of the workflow is executing at a time. By doing so, it ensures that one version is created and committed to main before we allow the next version to be created.

Updates the `bumpVersion` action to use the local version instead of tags

The bumpVersion action previously used tags to prevent version conflicts due to race conditions. i.e: when a version was created we would immediately tag it and push the tags. Then when creating a new version we would fetch the tags, get the highest one, and do that + 1. The problem created by that method was that we could not "register" a new version without pushing tags, and pushing tags triggers a staging deploy.

Now, we're using a "subroutine" and softprops/turnstyle to prevent race conditions, and we don't want to deploy to staging until the staging branch has been successfully updated. So I changed this action to once again just use the local version +1.

Replaces the `automerge` workflow with a new `updateProtectedBranch` subroutine

When we want to update a protected branch, we have to create an automerge a pull request to update that branch. This workflow does that synchronously.
staging can only be updated from main, and production can only be updated from staging
This workflow can be synchronously executed from within our createNewVersion workflow, to prevent version conflict race conditions.
This workflow also means we no longer need the automerge workflow.

Fixed Issues

Fixes https://github.com/Expensify/Expensify/issues/157916 https://github.com/Expensify/Expensify/issues/163576

Testing plan

Make sure the StagingDeployCash is not locked
Create a dummy PR.
Merge this PR and the dummy PR in quick succession.
Both PRs should create a new BUILD version. There should be no version conflict. A tag for each version should not be pushed yet.
For each, a bump-version PR should update the main branch, followed by another PR to update the staging branch from main.
Once the staging branch is updated, the deploy workflow should begin, create a tag for the updated BUILD version on the staging branch, and push tags.
Pushing tags should start the staging platformDeploy workflow. When that workflow completes, a comment should appear on this and the dummy PR stating that it was deployed to staging.
Both PRs should be added to the StagingDeployCash.
Lock the StagingDeployCash, and the lockCashDeploys workflow should begin.
A PATCH version should be created.
A PR to update the main branch should be created and automerged, followed by a PR to update the staging branch.
Once the PR to update staging is merged, the deploy workflow should begin, create a tag with the updated PATCH version, and push tags.
Pushing tags should start the staging platformDeploy workflow.
Create and merge another dummy PR. It should not result in the creation of a new version, and should not result in a deploy. We should see a comment like: This PR was not deployed to staging....
Write down all the un-QA'd PRs and unresolved deploy blockers on the open StagingDeployCash.
Check off all the items on the StagingDeployCash checklist, and close it with the :shipit: comment.
The finishReleaseCycle workflow should begin, and a pull request with production as the base and staging as the head should be created and automerged.
Once the PR to update production is merged, the deploy workflow should start, and create a new GH release for the PATCH version that was created in step 10.
Once that release is created, the platformDeploy workflow should begin a prod deploy. Once that completes, a comment should appear on this PR, the dummy PR, and all the PRs that were on the now-closed StagingDeployCash stating that they were deployed to production.
The finishReleaseCycle workflow should also bump the BUILD version and create a PR to update staging from main. This should result in a staging deploy.
The finishReleaseCycle workflow should also create a new StagingDeployCash issue, with the BUILD version from the previous step.
The dummy PR from step 14 should be included in the PR checklist for the new StagingDeployCash.
As a cleanup step, manually add any unverified PRs to the new StagingDeployCash (you wrote these down in step 15). The deploy blockers will no longer be deploy blockers, but should still be worked on with as much urgency as possible, as they will now be bugs on production.

Testing Template

Merging regular PR (w/ race condition)

Staging Deploy not locked
Two PRs:
1.
2.
preDeploy workflow run:
- Created BUILD version
- Updated main:
  - PR:
  - updateProtectedBranch workflow run:
- Updated staging:
  - PR:
  - updateProtectedBranch workflow run:
deploy workflow run:
- Tag pushed?
platformDeploy workflow run:
StagingDeployCash updated with new PRs and BUILD version?
"Deployed to staging" comment on merged PRs?

Locking `StagingDeployCash`

lockCashDeploys workflow run:
- Patch version created?
- Updated main:
  - PR:
  - updateProtectedBranch workflow run:
- Updated staging:
  - PR:
  - updateProtectedBranch workflow run:
- StagingDeployCash updated with new PATCH version?

Merging while `StagingDeployCash` is locked

Dummy PR:
preDeploy workflow:
- "Not deployed to staging" comment?
- StagingDeployCash not updated?

Prod deploy

roryabraham · 2021-04-16T21:10:35Z

Okay, there are still more simplifications we can do after this, but we can move in increments. I think this PR is enough to resolve the problem at hand (i.e: only deploy to staging when the staging branch is updated, and same for production). There are several more simplifications we can do after this before adding complexity with the CP flows.

roryabraham · 2021-04-16T21:47:31Z

I took this off draft, and I could use some reviews at this point. That said, the likelihood that this won't break anything and will just work first try is slim. To minimize disruptions, @AndrewGable and I were thinking we would schedule a day to live-test this, and let Applause skip QA that day. So please review but don't merge 🙂

AndrewGable

Looking good! I like where this is headed for sure. It seems like there are still some TODOs left before we can talk about testing this, is that correct?

.github/workflows/automerge.yml

.github/workflows/createNewVersion.yml

roryabraham · 2021-04-20T16:48:10Z

there are still some TODOs left before we can talk about testing this, is that correct?

Correct, we need to either get those 3rd-party PRs merged or point at my fork of the repos for now. We could probably benefit from doing some more atomic testing of the updated 3rd-party actions using Public-Test-Repo before diving in to try and test this whole PR

Jag96

We could probably benefit from doing some more atomic testing of the updated 3rd-party actions using Public-Test-Repo before diving in to try and test this whole PR

This sounds like a good idea, what specific tests need to be run?

Jag96 · 2021-04-21T16:19:14Z

.github/workflows/finishReleaseCycle.yml


+      # TODO: only need to create this tag because of how the GitUtils work


I'm not sure what this means, is this still a TODO?

deetergp · 2021-04-21T20:14:04Z

.github/actions/bumpVersion/bumpVersion.js

-        return exec(`npm --no-git-tag-version version ${newVersion} -m "Update version to ${newVersion}"`);
-    })
+console.log(`Setting npm version to ${newVersion}`);
+exec(`npm --no-git-tag-version version ${newVersion} -m "Update version to ${newVersion}"`)


You can just do "Update version to %s" here. (ref)

deetergp · 2021-04-21T20:38:47Z

.github/workflows/createNewVersion.yml

+
+      - name: Set up git
+        run: |
+          git fetch


NAB: Do you know if these are chained like && in bash, in that the next command won't run unless the previous command exits with a return code of 0?

That's a good question ... I do not know the answer.

roryabraham · 2021-04-27T21:20:36Z

Got some movement on this PR and updated it after the maintainer's review.

roryabraham · 2021-05-11T21:51:00Z

.github/workflows/automerge.yml

-      needs: getPullRequestMergeability
-      if: github.event.pull_request.base.ref == 'production' && github.actor == 'OSBotify' && github.event.label.name == 'automerge'
-      steps:
+        # TODO: Once https://github.com/hmarr/auto-approve-action/pull/186 is merged, point back at the non-forked repo


Honestly, I'm not sure if just pointing at a forked repo like this will work, or if I need to checkout that repo in the workflow or publish the action in that repo or something

Seems like this works just fine as-is: https://github.com/Andrew-Test-Org/Public-Test-Repo/pull/49/checks?check_run_id=2568980822

roryabraham · 2021-05-11T22:41:32Z

🎉 pascalgn/automerge-action#149 has been merged 🎉

…ctedBranch

roryabraham · 2021-05-13T19:45:49Z

Okay, taking this off hold. Let's do this thang.

Jag96 · 2021-05-13T19:51:39Z

@deetergp dismissing the requested changes here since they were for minor refactors and we're going to be testing this today. Will follow up w/ any minor fixes.

Dismissing minor issues to test

OSBotify · 2021-05-13T20:23:26Z

🚀 Deployed to staging in version: 1.0.43-6🚀

platform	result
🤖 android 🤖	success ✅
🖥 desktop 🖥	success ✅
🍎 iOS 🍎	success ✅
🕸 web 🕸	success ✅

OSBotify · 2021-05-13T23:05:15Z

🚀 Deployed to production in version: 1.0.44-0🚀

platform	result
🤖 android 🤖	failure ❌
🖥 desktop 🖥	success ✅
🍎 iOS 🍎	success ✅
🕸 web 🕸	success ✅

roryabraham added 2 commits April 9, 2021 12:43

CreateNewVersion workflow draft

6f7b7a1

Add comment with new PR URL

19e2865

roryabraham changed the title ~~Rory move version to its own workflow~~ Move version-bump and automerge code to its own workflow Apr 9, 2021

roryabraham added 3 commits April 16, 2021 10:41

Merge branch 'main' into Rory-MoveVersionToItsOwnWorkflow

5c1aeb7

Update master to main

54ad9d4

Use createNewVersion with triggerAndWait from other workflows

ce6dc5d

roryabraham changed the title ~~Move version-bump and automerge code to its own workflow~~ [No QA] Move version-bump and automerge code to its own workflow Apr 16, 2021

roryabraham self-assigned this Apr 16, 2021

roryabraham added 3 commits April 16, 2021 12:59

Make automerge its own subroutine

bee0e99

Update bumpVersion to use local version instead of using tags

61a7cf0

Only deploy staging once staging branch is updated

f0ca0bb

roryabraham requested review from AndrewGable, Jag96 and deetergp April 16, 2021 21:07

roryabraham marked this pull request as ready for review April 16, 2021 21:08

roryabraham requested a review from a team as a code owner April 16, 2021 21:08

MelvinBot requested review from nkuoch and removed request for a team April 16, 2021 21:08

Get rid of automerge label

ff1798f

roryabraham changed the title ~~[No QA] Move version-bump and automerge code to its own workflow~~ [HOLD] [No QA] Move version-bump and automerge code to its own workflow Apr 16, 2021

Rebuild GH actions

9c4287b

AndrewGable reviewed Apr 20, 2021

View reviewed changes

.github/workflows/automerge.yml Outdated Show resolved Hide resolved

.github/workflows/createNewVersion.yml Outdated Show resolved Hide resolved

stitesExpensify removed the request for review from nkuoch April 20, 2021 19:24

Jag96 reviewed Apr 21, 2021

View reviewed changes

deetergp previously requested changes Apr 21, 2021

View reviewed changes

roryabraham mentioned this pull request May 7, 2021

[No QA] Create triggerWorkflowAndWait action #2495

Merged

roryabraham commented May 11, 2021

View reviewed changes

Point back at original automerge-action repo

477e985

roryabraham added 6 commits May 11, 2021 15:58

Create separate workflows to update staging and production branches

a3b404d

Replace automerge + updateStaging + updateProduction with updateProte…

59b1edb

…ctedBranch

Wrap if in brackets

c111446

Update README

71a029c

Add changedFiles validation back in

8dfd03c

fix outdated references to steps.bumpVersion.outputs.NEW_VERSION

e532838

roryabraham changed the title ~~[HOLD] [No QA] Move version-bump and automerge code to its own workflow~~ [No QA] Move version-bump and automerge code to its own workflow May 13, 2021

Jag96 approved these changes May 13, 2021

View reviewed changes

roryabraham mentioned this pull request May 13, 2021

Dummy Markdown change #2867

Merged

Jag96 merged commit 4d5f118 into main May 13, 2021

Jag96 deleted the Rory-MoveVersionToItsOwnWorkflow branch May 13, 2021 19:53

Jag96 mentioned this pull request May 13, 2021

Revert "Dummy Markdown change" #2869

Merged

roryabraham mentioned this pull request May 13, 2021

Use fromJSON instead of JSON literal in contains #2870

Merged

roryabraham mentioned this pull request May 13, 2021

Deploy Checklist: Expensify.cash 2021-05-13 #2905

Closed

4 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[No QA] Move version-bump and automerge code to its own workflow #2329

[No QA] Move version-bump and automerge code to its own workflow #2329

roryabraham commented Apr 9, 2021 •

edited

Loading

roryabraham commented Apr 16, 2021

roryabraham commented Apr 16, 2021

AndrewGable left a comment

roryabraham commented Apr 20, 2021

Jag96 left a comment

Jag96 Apr 21, 2021

deetergp Apr 21, 2021

deetergp Apr 21, 2021

roryabraham Apr 21, 2021

roryabraham commented Apr 27, 2021

roryabraham May 11, 2021

roryabraham May 12, 2021

roryabraham commented May 11, 2021

roryabraham commented May 13, 2021

Jag96 commented May 13, 2021

OSBotify commented May 13, 2021

OSBotify commented May 13, 2021


		# TODO: only need to create this tag because of how the GitUtils work

[No QA] Move version-bump and automerge code to its own workflow #2329

[No QA] Move version-bump and automerge code to its own workflow #2329

Conversation

roryabraham commented Apr 9, 2021 • edited Loading

Details

Creates a new workflow called createNewVersion that:

Updates the bumpVersion action to use the local version instead of tags

Replaces the automerge workflow with a new updateProtectedBranch subroutine

Fixed Issues

Testing plan

Testing Template

Merging regular PR (w/ race condition)

Locking StagingDeployCash

Merging while StagingDeployCash is locked

Prod deploy

roryabraham commented Apr 16, 2021

roryabraham commented Apr 16, 2021

AndrewGable left a comment

Choose a reason for hiding this comment

roryabraham commented Apr 20, 2021

Jag96 left a comment

Choose a reason for hiding this comment

Jag96 Apr 21, 2021

Choose a reason for hiding this comment

deetergp Apr 21, 2021

Choose a reason for hiding this comment

deetergp Apr 21, 2021

Choose a reason for hiding this comment

roryabraham Apr 21, 2021

Choose a reason for hiding this comment

roryabraham commented Apr 27, 2021

roryabraham May 11, 2021

Choose a reason for hiding this comment

roryabraham May 12, 2021

Choose a reason for hiding this comment

roryabraham commented May 11, 2021

roryabraham commented May 13, 2021

Jag96 commented May 13, 2021

OSBotify commented May 13, 2021

OSBotify commented May 13, 2021

roryabraham commented Apr 9, 2021 •

edited

Loading

Creates a new workflow called `createNewVersion` that:

Updates the `bumpVersion` action to use the local version instead of tags

Replaces the `automerge` workflow with a new `updateProtectedBranch` subroutine

Locking `StagingDeployCash`

Merging while `StagingDeployCash` is locked