Add new job to leave comment to new contributor

[aldo-expensify]

Hey @roryabraham , I added you as a reviewer as I think you know very well how this is supposed to be implemented :)

I didn't spot any problem with the code provided in the GH issue besides changing çount for count

Details

Add new job "newContributorReminder" to preDeploy.yml. Steps in this job:

1. Checkout repository
2. Find last merged PR to get author
3. Get count of PR's done by this author
4. If count of PR's is exactly 1, leave a comment in the merged PR reminding the contributor about things to expect/responsibilities.

I have these doubts about this:

1. I would add the internal QA label, is that correct in this case?
2. In the first step, should we keep fetch-depth: 0 for the uses: actions/checkout@5a4ac9002d0be2fb38bd78e4b4dbde5606d7042f? I left it there because removing it would only make sense to me for performance reasons, but I guess that's not too important here. Fetching with a narrower scope could make it miss somethings we need to find? The PR's?
3. What happen if two different first contributors' PRs are merged about the same time. Would this job be able to run between each of these PRs? or probably one of them would miss it. I'm guessing that this would be a very rare case, and if one contributor misses his comment, it's not a big deal, but anyway I'm curious about that case :)

Fixed Issues

$ https://github.com/Expensify/Expensify/issues/176233

Tests

• Create a PR and merge it with an account that has not done any PR before
• The PR should get the new comment
• Do a PR again with the same account and merge it
• The new PR shouldn't get the new comment

QA Steps

Reach out to @aldo-expensify to perform QA of this issue

[roryabraham]

I would add the internal QA label, is that correct in this case?

We don't yet have an internal QA checklist for New Expensify. You'll just have to remember to QA this in the next deploy cycle by submitting a PR with a new GitHub account (or just verifying that it works for the next first-time contributor PR merged).

[roryabraham]

In the first step, should we keep fetch-depth: 0

I think it's safe to remove in this case, so we should.

[roryabraham]

What happen if two different first contributors' PRs are merged about the same time.

Two separate jobs would happen in different GHA runners at the same time. Should still work fine.

[aldo-expensify]

I would add the internal QA label, is that correct in this case?

We don't yet have an internal QA checklist for New Expensify. You'll just have to remember to QA this in the next deploy cycle by submitting a PR with a new GitHub account (or just verifying that it works for the next first-time contributor PR merged).

Sounds good. [NO QA] should stay there, right? because this won't be done by applause

[aldo-expensify]

Update: addressed comments!

[roryabraham]

Sounds good. [NO QA] should stay there, right? because this won't be done by applause

Yep, or you can utilize applause and make the QA steps "reach out to @aldo-expensify to perform QA of this issue".

[roryabraham]

LGTM

[OSBotify]

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

[roryabraham]

Looks like this worked 🎉 #5060 (comment)

[OSBotify]

🚀 Deployed to staging by @nickmurray47 in version: 1.0.98-2 🚀

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

[mvtglobally]

@aldo-expensify, PR has been deployed. Let us know if you want us to perform any QA steps

[OSBotify]

🚀 Deployed to production by @Jag96 in version: 1.0.99-4 🚀

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

[aldo-expensify]

@aldo-expensify, PR has been deployed. Let us know if you want us to perform any QA steps

Sorry, I missed this message.

No need @mvtglobally , thanks!