Incorrect CP messages are showing up

[luacmartins]

Problem

We ran a CP for this PR, but it seems like we got duplicated CP messages added to two different issues for the same staging version.

• [No QA] Fix uploading web assets to GitHub Releases #46438 (comment)
• [Search v2] Add displaying advanced filter values and type/status #46022 (comment) (this PR had been merged before the deploy, so it was already in staging)

It seems like all issues in the checklist got the cherry pick comment, instead of the deploy one

Additionally, it seems like we auto-assigned Chirag to the checklist for whatever reason.

Solution

Investigate

[melvin-bot]

Triggered auto assignment to @greg-schroeder (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[roryabraham]

The problem is that this variable only looks at the tag for the deploy. However, sometimes deploys are "batched" with deploys because of this cancel-in-progress key.

So we really need to look at another piece of data to determine if a PR is being CP'd or deployed via the normal process.

[roryabraham]

Got #46535 prettymuch ready, but I'd like to wait for some CP'd merge commits to appear on staging so I can double-check what the commit messages look like before I put that PR in for review

[roryabraham]

Sample commit message for a CP'd PR, pulled from staging log (had to do it after CP'ing some stuff because full staging deploys delete these commits and replace them with whatever's on main)

Merge pull request #46679 from neonbhai/selection-dropdown-fix
    
Fix: Dropdown button is not disabled when no selection is made
(cherry picked from commit 7b1b260ee9ed71e253e25642f95d362d70259368)

[greg-schroeder]

PR still in progress

[roryabraham]

ok, I've gotten this to the point where we can see which PRs were CP'd and in what versions. However, now we need a way to determine who actually triggered the CP workflow.

I tried listing cherryPick workflow runs but it doesn't seem like there's really a way to associate runs with a version. meanwhile, all platformDeploy runs are triggered by OSBotify

So my best idea right now is to try and update the cherryPick workflow to run the CP commits as the deployer, not OSBotify. But that could have all kinds of side-effects that would need to be carefully considered 😬

[melvin-bot]

@greg-schroeder, @roryabraham Whoops! This issue is 2 days overdue. Let's get this updated quick!

[roryabraham]

update the cherryPick workflow to run the CP commits as the deployer, not OSBotify

Looks like we're already trying to do this, but it doesn't look like it's working: 8d2f90b

[roryabraham]

ok, chatted with @francoisl and we came up with a clever solution. PR ready for review

[roryabraham]

PR merged

[greg-schroeder]

Thanks @roryabraham! Awaiting deploy to staging -> prod

[roryabraham]

This should be fixed now