Fix check-for-reproducer action not adding Missing Repro comment

[kacperkapusciak]

Summary:

This PR fixes a bug where GitHub Actions bot didn't add a comment when "Needs: Repro" label was present in an issue.

When a maintainer adds the label manually the bot comments with "Missing Reproductible Example" as normally.

It seems like the problem occurred because of a difference in a sandbox repository and the proper facebook/react-native repo environment.

My sandbox that I used to test #38338 had an "bot" account with Personal Access Token setup to reply to issues. Turns out that bots using PAT have more permissions and can trigger one action from the other.

The solution is to send the comment directly from the checkForReproducer action. This won't collide with other actions but sadly will duplicate the sending logic into two actions.

This PR also makes the bot respect when a maintainer removes and adds a label by hand and won't alter the maintainer decision.

Related to ☂️ #35591

Changelog:

[INTERNAL] [FIXED] - Fix check-for-reproducer action not adding Missing Repro comment

Test Plan:

When issue is added

1. Bot adds comment and "Needs: Repro" label when no reproducer is present in the issue body
   

2. Bot adds comment and "Needs: Repro" label when a repository not connected to the user's name was submitted

3. Bot doesn't trigger when Snack is present in issue body

4. Bot doesn't trigger when Github Repo under the user's name is present in the issue body

When issue body is edited

1. Bot removes the comment and "Needs: Repro" label when user edits the issue and adds a link to snack

2. Bot removes the comment and "Needs: Repro" label when user edits the issue and adds a GitHub repo under user's name

2. Bot triggers when user removes the reproduction from issue body

When comment is added

1. Bot removes the comment and the Needs Repro label when user submits a repo under their name
   

2. Bot removes the comment and the Needs Repro label when any user submits a snack
   

3. Bot removes the comment and the Needs repro label when other user submits a repo under their name

When maintainer changes the label

1. When maintainer changes the label it turns off the action, needs repro bot won't interfere with the issue anymore

[analysis-bot]

Platform	Engine	Arch	Size (bytes)	Diff
android	hermes	arm64-v8a	8,843,818	-2
android	hermes	armeabi-v7a	8,152,943	-1
android	hermes	x86	9,349,584	-4
android	hermes	x86_64	9,192,338	+2
android	jsc	arm64-v8a	9,455,584	-1
android	jsc	armeabi-v7a	8,636,721	+0
android	jsc	x86	9,538,674	+0
android	jsc	x86_64	9,781,970	-2

Base commit: 5705661
Branch: main

[cortinico]

My sandbox that I used to test #38338 had an "bot" account with Personal Access Token setup to reply to issues. Turns out that bots using PAT have more permissions and can trigger one action from the other.

If having a bot with a PAT can solve this, I'll gladly set up one for @react-native-bot and add the token to the setup

[kacperkapusciak]

If having a bot with a PAT can solve this, I'll gladly set up one for @react-native-bot and add the token to the setup

I'm afraid of a case where there would an infinite loop somewhere I haven't tested yet (or 20 max invocations as GitHub docs says) so maybe it's better to have it that way

[cortinico]

so maybe it's better to have it that way

What do you mean with "that way" here?

[kacperkapusciak]

@cortinico sorry, I meant without the PAT so loops in GH action invocation wouldn't be possible. I think it's safer

[facebook-github-bot]

@cortinico has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

[kacperkapusciak]

@cortinico I coded it so it when a non-author (a maintainer) alters the "Needs: Repro" label it turns off the action completely

Q: Do you think it should attempt to remove the "Missing Repro" comment when a maintainer removes the label before it turns off?

[facebook-github-bot]

@cortinico merged this pull request in 3f78fa9.

[cortinico]

Q: Do you think it should attempt to remove the "Missing Repro" comment when a maintainer removes the label before it turns off?

Not necessarily. Let's keep it as it is for now, and we can refine it afterwards