-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
Update getPullRequestsMergedBetween logic #6906
Conversation
Question: Is it valuable to aggregate those many long testing steps into an automated script? Should be pretty easy... The only tricky part is the CP conflicts, but those aren't super critical and I can change the steps a bit so there's no conflict. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wohoo 🎉 This is absolutely great work and investigation here. I haven't found any typos or any changes I would suggest. I believed you have tested this thoroughly so going to approve it now.
There is one thing I can think of and that is some more extensive description of this entire process and why we need to do it (parse and filter the commits in this way). Since it took us a long time to figure it out and hopefully, this will work and solve our issues, would you write some SO to cover this for future engineers to understand better?
Thank you for working on this!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NAB, we repeat some code in all of these instances that could probably be dry'd up, but it was like that before.
Triggered auto assignment to @robertjchen ( |
@ctkochan22 looks like this was merged without passing tests. Please add a note explaining why this was done and remove the |
✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release. |
Double checked with @Jag96 , this sounds like https://github.com/Expensify/Expensify/issues/189984 Removing emegency label |
🚀 Deployed to staging by @ctkochan22 in version: 1.1.26-2 🚀
|
🚀 Deployed to staging by @ctkochan22 in version: 1.1.27-0 🚀
|
🚀 Deployed to production by @roryabraham in version: 1.1.27-1 🚀
|
Okay, starting QA using these 6 PRs: A: #7161
|
Oh, and |
Finished QA here 🎉 |
@roryabraham Amazing job on this one, Rory! |
cc @mountiny @AndrewGable @Jag96
Details
This (hopefully) fixes long-broken logic where duplicate PRs show up in checklists / deploy comments or are excluded from checklists / deploy comments in error.
See this comment for details.
Fixed Issues
$ #4977
Tests
I wrote an automated test script to run these steps on an ongoing basis, but here are the manual testing steps:
Setup steps
If needed, install
jq
:brew install jq
.Create directory for dummy repo:
mkdir DummyRepo && cd DummyRepo
Initialize npm project so that we can test the node script w/ underscore dependency:
npm init
(use0.0.1
as the initial version).Install underscore:
npm install underscore && npm i
Create a tiny node script we'll use for testing:
touch ./getPullRequestsMergedBetween.js && chmod u+x ./getPullRequestsMergedBetween.js
Initialize
DummyRepo
as a git repo withmain
as the default branch.git init -b main git add package.json package-lock.json getPullRequestsMergedBetween.js git commit -m "Initial commit"
Update the version to
1.0.0
and tag the commit. This is only necessary so that we have a "previous tag".Create
staging
andproduction
branches off ofmain
:Tag the version on staging:
git checkout staging git tag $(cat ./package.json | jq -r .version) git checkout main
Scenario 1: Merge a pull request when the checklist is unlocked
Create "PR 1", and merge that PR to
main
.Bump the version to
1.0.1
:Merge
main
intostaging
:git checkout staging git checkout -b update-staging-from-main git merge -Xtheirs main git checkout staging git merge update-staging-from-main --no-ff -m "Merge pull request #3 from Expensify/update-staging-from-main" git branch -d update-staging-from-main
Tag
staging
:git checkout staging git tag $(cat ./package.json | jq -r .version) git checkout main
From
staging
, verify thatnode getPullRequestsMergedBetween.js 1.0.0 1.0.1
outputs:Scenario 2: Lock the deploy checklist
Bump the version to
1.1.0
onmain
Merge
main
intostaging
git checkout staging git checkout -b update-staging-from-main git merge -Xtheirs main git checkout staging git merge update-staging-from-main --no-ff -m "Merge pull request #5 from Expensify/update-staging-from-main" git branch -d update-staging-from-main
Tag the new version on
staging
git checkout staging git tag $(cat package.json | jq -r .version)
From
staging
, verify thatnode getPullRequestsMergedBetween 1.0.0 1.1.0
outputs:Scenario 3: Merge another pull request, but don't CP it
Create "PR 6", and merge that PR to
main
:Scenario 4: Merge another pull request and CP it to staging
Create "PR 7" and merge that PR to
main
:Update version to
1.1.1
onmain
:Cherry pick PR 7 (and the version-bump) to
staging
:First, find the merge commit hash for PR 7 using
git log
. Save it to a local variable calledMERGE_7
Next, find the merge commit hash for PR 8 using
git log
. Save it to a local variable calledMERGE_8
Next, begin using the
cherry-pick
command to CP our changes:At this point, there will be conflicts in
CHANGELOG.txt
. Fix those conflicts to include only the ones to CP (i.e.: "changes from PR 7").Tag the new version on
staging
:git checkout staging git tag $(cat package.json | jq -r .version)
From
staging
, verify thatnode getPullRequestsMergedBetween 1.0.0 1.1.1
outputs:Note: It's fine that PR 9 is included here. It will be filtered out of the deploy checklist at a later step because it's created by
OSBotify
.Scenario 5: Close the checklist
Scenario 5A: Run the production deploy
Update production from staging
git checkout production git checkout -b update-production-from-staging git merge -Xtheirs staging git checkout production git merge update-production-from-staging --no-ff -m "Merge pull request #10 from Expensify/update-production-from-staging" git branch -d update-production-from-staging
Verify that
node getPullRequestsMergedBetween 1.0.0 1.1.1
outputs:Scenario 5B: Run the staging deploy and create a new checklist
Bump version to
1.1.2
onmain
:Update
staging
frommain
:git checkout staging git checkout -b update-staging-from-main git merge -Xtheirs main git checkout staging git merge update-staging-from-main --no-ff -m "Merge pull request #12 from Expensify/update-staging-from-main" git branch -d update-staging-from-main
Tag new version on
staging
:git checkout staging git tag $(cat package.json | jq -r .version)
Verify that
node getPullRequestsMergedBetween 1.1.1 1.1.2
outputs:Scenario 6: Merge another pull request with the checklist unlocked
Create "PR 13", and merge that PR to
main
.Bump the version to
1.1.3
:Merge
main
intostaging
:git checkout staging git checkout -b update-staging-from-main git merge -Xtheirs main git checkout staging git merge update-staging-from-main --no-ff -m "Merge pull request #15 from Expensify/update-staging-from-main" git branch -d update-staging-from-main
Tag
staging
:git checkout staging git tag $(cat ./package.json | jq -r .version)
From
staging
, verify thatnode getPullRequestsMergedBetween.js 1.1.1 1.1.3
outputs:In addition to the above, I updated some automated unit tests.
QA Steps
Here are the live-testing steps for this PR... We'll need 5 PRs A-E.
CP Staging
labelCP Staging
labelCP Staging
label, then manually CP it.A
,B
,D
,E
should all receive "deployed to production" commentC
should not receive "deployed to production" comment.C
should be included in the new checklistA
,B
,D
,E
should all not be included in the new checklist.C
should receive "deployed to staging" comment.A
,B
,D
,E
should all not receive "deployed to staging" comment.Tested On
GitHub only