-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Do not include CP merge commits in the list of PR merge commits #6165
Conversation
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.
However, since this is potentially very problematic change if this would fail for whatever reason, I would try to test this on couple of latest releases, which I have not had a time to do so yet, so I am putting this on HOLD
for now.
return _.map( | ||
[...localGitLogs.matchAll(/Merge pull request #(\d{1,6}) from (?!Expensify\/(?:master|main|version-))/g)], | ||
[...localGitLogs.matchAll(/{\[Merge pull request #(\d{1,6}) from (?!(?:Expensify\/(?:master|main|version-))|(?:[^(\]})]*\(cherry picked from commit .*\)\s*\]}))/g)], |
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.
So this has been a bit of magic and fiddling around with the regex, but this is what worked for the cases I could think of.
@mountiny What's your testing plan for this PR? Any way I can help? |
@roryabraham Got stuck with other issues and university. I have some coursework to focus on currently, but gave it a some quick testing now as I realize this is quite annoying bug. Testing planFirstly, I went to App repository Actions and sound the Then I have found the latest one which has successfully completed: https://github.com/Expensify/App/runs/4214468887 Then I opened the Next, I make sure my local tags are synced with remote using: Now, I run
I have tested this in the https://regex101.com/ tool but unfortunately I have came across a regression and that is PR
The reason why it is matched is that there is the I need to update the regex currently used |
We can't really use the character class there as this will always be prone to error in case the developer would use the character in the commit message or in this case PR title. Unless, just got the idea now, we could update the cherry pick script to strip the Do you have any ideas how we could do this with plain regex and the structure we have now (or using the |
I spent some time trying to get this to work using a single regex with the example you were testing against, but didn't have any success. I believe it might be possible using a nested negative lookahead to match "anything except An alternative would be to use two regex in a row. So we'd:
|
@roryabraham I think going the way to split it into two regex is a good way... no reason to spend more time trying to find out some complex regex solving this. I will try to update the code in coming days. Having lots of coursework these weeks, so apologies for slower progress. |
// Parse the git log into an array of commit messages between the two refs | ||
const commitMessages = _.map( | ||
[...localGitLogs.matchAll(/{\[([\s\S]*?)\]}/gm)], |
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.
I have used your advice and split it up to two regexps. Here, I get the individual commit messages which are all inside of the {[]}
.
const pullRequestIDs = _.reduce(commitMessages, (mergedPRs, commitMessage) => { | ||
const mergeCommits = [...commitMessage.matchAll(/Merge pull request #(\d{1,6}) from (?!(?:Expensify\/(?:master|main|version-))|(?:([\s\S]*?)\(cherry picked from commit .*\)\s*))/gm)]; | ||
|
||
// Get the PR number of the first match (there should not be multiple matches in one commit message) | ||
if (_.size(mergeCommits)) { | ||
mergedPRs.push(mergeCommits[0][1]); | ||
} | ||
return mergedPRs; | ||
}, []); |
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.
And then I decided to use reduce on the list of commit messages. I use the regexp we have developed (slightly adjusted) to match the PR numbers. Then if some match found, I push the group to the accumulator array.
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.
@roryabraham Updated the parsing logic as we have discussed in this PR. The unit tests all pass well. Not sure if the matching logic inside of the reduce is the most elegant way to do this. Please, let me know if you can think of some nicer way!
Thank you for your and @tylerkaraszewski review on this one!
Lol, I got picked as reviewer but I basically have no idea how any of this works? Does someone want to walk me through the review, or should I let @roryabraham handle it? |
@tylerkaraszewski I can review 😁 But in case you're curious, the TL;DR is:
|
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.
I think this looks good to me 👍
Thank you @roryabraham 🙇 |
Let's test this out! |
Well, it didn't break the checklist, which is a good sign 👍 We should keep an eye on this PR, as an example. When we lock the checklist it should not get a comment saying it was deployed to staging, because it's already been CP'd to staging and deployed to production. |
Great news! |
🚀 Deployed to staging by @roryabraham in version: 1.1.16-13 🚀
|
@roryabraham @mountiny Can you validate and check this off? |
@mountiny It seems like this didn't work. Check out this checklist ... #6535 was CP'd to staging then deployed to production but is present on a new checklist. |
🚀 Deployed to production by @roryabraham in version: 1.1.17-7 🚀
|
Details
We are having several issues which are caused by the fact that when PR is CP'ed to staging, this creates a new commit in git history, which starts the same as every other merge commit ie:
Merge pull request #4444
.This duplicate then causes multiple problems, see linked issue for details.
Fixed Issues
$ #4977
Tests
Updated the GitUtilsTest.js to have unit tests
QA Steps
Once deployed to production, we will need to monitor for example staging deploy message to see, if the pull requests, which have been cherry-picked to staging will appear in two deploy checklists in a row or if the PRs will get deploy messaged for two consequent deploys. They should not, the PR should only be considered as part of the deploy into thich it was CP'ed.
Tested On
Unit tests.