Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[No QA] Tag staging instead of main before updating checklist #5013

Merged
merged 5 commits into from
Sep 3, 2021

Conversation

roryabraham
Copy link
Contributor

Details

Right here we're pulling main and creating a tag with the new version. Then in the next two steps we:

  1. maybe CP the PR, and
  2. always update the checklist using that tag as a reference to figure out what PRs were merged.

However, the tag created from main might include PRs that were merged but not deployed to staging. For example:

  1. PR 1 is merged.
  2. Tag A is created that includes PR 1.
  3. Staging deploy is locked. Other stuff happens that doesn't matter in this example.
  4. PR 2 is merged. No deploy happens and no tag is created.
  5. PR 3 is merged + CP'd.
  6. Tag B is created off main, and includes PR 2 in its history. But PR 2 was not deployed to staging

This PR should fix this issue by tagging staging instead of main before updating the checklist.

Fixed Issues

Hopefully might (at least partially) fix https://github.com/Expensify/Expensify/issues/168349

Tests

  1. With the deploy checklist locked, merge a PR (A).
  2. Merge + CP another PR (B).
  3. The checklist should be updated to include B but not A.

QA Steps

None.

@roryabraham roryabraham self-assigned this Sep 2, 2021
@roryabraham roryabraham requested a review from a team as a code owner September 2, 2021 05:44
@MelvinBot MelvinBot requested review from tgolen and removed request for a team September 2, 2021 05:44
@roryabraham
Copy link
Contributor Author

Also cc @Jag96 since I know you've worked on this issue before.

@@ -105,6 +101,13 @@ jobs:
WORKFLOW: cherryPick.yml
INPUTS: '{ "PULL_REQUEST_NUMBER": "${{ needs.chooseDeployActions.outputs.mergedPullRequest }}", "NEW_VERSION": "${{ env.NEW_VERSION }}" }'

# Note: we need to create this tag but not push it, because GitUtils.getPullRequestsMergedBetween uses tags to generate a list of merged pull requests
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for working on this comment! I think there is still some room for improvement though. It needs to explain why the tag isn't being pushed, and I think it should also explain how tags are used in getPullRequestsMergedBetween. Something like this:

Create a tag for this version so that GitUtils.getPullRequestsMergedBetween can generate a list of merged pull requests that happened between two release version tags. It's not necessary to push this tag because... XYZ.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's great feedback! One of my goals for the GHA code is to make it more approachable to new contributors, and there are definitely a few "gotchas" hiding in here. So it's definitely good to explain this one in more detail :)

I updated the comment, let me know what you think!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see 2 other places where the old comment still exists, can you update those as well?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated again!

AndrewGable
AndrewGable previously approved these changes Sep 2, 2021
@roryabraham roryabraham requested a review from tgolen September 2, 2021 22:51
Jag96
Jag96 previously approved these changes Sep 3, 2021
tgolen
tgolen previously approved these changes Sep 3, 2021
Copy link
Contributor

@tgolen tgolen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, that's a much better comment. Thanks! I like the mention of the trigger for the staging deploy. It made me think of another question though...

What happens to the local tag? Does the tag get pushed as part of the staging deploy, or does the tag just remain on the local repo and never get used again?

Maybe instead of saying:

It's important not to push this tag now

It is better to say

Don't push this tag to the remote now because it will be pushed when the staging deploy is triggered in the deploy.yml workflow.

@tgolen
Copy link
Contributor

tgolen commented Sep 3, 2021

Updated my previous copy suggestion

@roryabraham roryabraham dismissed stale reviews from tgolen and Jag96 via 213e0f2 September 3, 2021 19:17
Copy link
Contributor

@tgolen tgolen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for that last change!

@tgolen tgolen merged commit 0174866 into main Sep 3, 2021
@tgolen tgolen deleted the Rory-FixCPLocalTag branch September 3, 2021 20:02
@OSBotify
Copy link
Contributor

OSBotify commented Sep 3, 2021

✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

@OSBotify
Copy link
Contributor

OSBotify commented Sep 4, 2021

🚀 Deployed to staging by @tgolen in version: 1.0.93-2 🚀

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

@OSBotify
Copy link
Contributor

OSBotify commented Sep 8, 2021

🚀 Deployed to production by @yuwenmemon in version: 1.0.94-1 🚀

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants