Assign CP PRs to the deployer that triggered them

[HorusGoul]

Details

Adds a new step in the cherry-pick job to assign the deployer to the PR with conflicts that need to be fixed manually.

Fixed Issues

$ #4036

Tests/QA Steps

1. Create a PR with changes in a given file.
2. Give the PR the CP Staging label.
3. Merge the PR.
4. Create another PR with changes in the same file (to ensure that there will be conflicts on staging).
5. Give the PR the CP Staging label.
6. Merge the PR.
7. The CP PR created for the second PR will be created but not automerged, due to conflicts.
8. The CP PR should be auto-assigned to the author of the original (second) PR.

[pecanoro]

Ohh this is going to be really hard to QA since we have to actually modify files. Do you have any suggestions of what files we could modify? Maybe a README file or something? Should we simply hope for the best and see if it works when this happens? Also, I just discovered we have a CP label haha

[HorusGoul]

@pecanoro Yes! I'd also say changing a README file is the easiest way to test this.

[roryabraham]

Couple things here:

1. In order to add or adjust the inputs or outputs of a GH action, we need to also adjust the action metadata file
2. Now that this action it doing more than getting the merge commit for a pull request, we should rename it to something more generic, perhaps just getPullRequestDetails
3. I do wonder if there's an existing community action to just get all the details for an arbitrary pull request. If so, we could maybe use that and get rid of this custom action altogether.

[roryabraham]

The only community action I found is this one, which doesn't look like it has all the outputs we need. So there are two choices:

Continue with our own custom action, include only the outputs we need, and rename it do something more generic like getPullRequestDetails

OR

1. Fork that community action to add outputs for:
   1. merge_commit_sha
   2. merged_by
2. Point our workflow at the forked action
3. Create a PR to update the community action. Once that PR is merged, point our workflow back at the upstream.

[roryabraham]

Up to you which you prefer!

[HorusGoul]

I'm going to go with the first option, as we have this custom logic related to the OSBotify actor, and we would still need a custom action for that.

[pecanoro]

Is it ready for another review? I see you updated the PR

[roryabraham]

All yours @pecanoro

[OSBotify]

🚀 Deployed to staging by @pecanoro in version: 1.0.92-6 🚀

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

[roryabraham]

@HorusGoul this is going to need internal QA – we know that it didn't break the CP flow (because we ran a CP this morning), but we still need to verify that it works as expected. Not going to block the deploy on this because there's no good reason to - it doesn't affect any of the app code.

[OSBotify]

🚀 Deployed to production by @roryabraham in version: 1.0.93-1 🚀

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