Fix check-for-reproducer never removing "Needs: Repro" once react-native-bot applied it - #58429
Fix check-for-reproducer never removing "Needs: Repro" once react-native-bot applied it#58429bjjeong wants to merge 1 commit into
Conversation
|
Hi @bjjeong! Thank you for your pull request and welcome to our community. Action RequiredIn order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you. ProcessIn order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA. Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks! |
…ive-bot applied it hasMaintainerChangedLabel treats every "Needs: Repro" label event by a non-Bot actor other than the author as a maintainer decision. react-native-bot, the account check-for-reproducer.yml runs as, is a regular user account (actor.type === 'User'), so the bot's own initial label satisfies that check and every later run exits before looking for a reproducer. Authors who edit a valid reproducer into the issue can therefore never get the label removed (e.g. react#58427; all recently labeled issues show the same). Ignore react-native-bot's own label events alongside GitHub App events so that only human label changes count as maintainer intervention, and add a unit test for the script covering the regression and the existing behaviours. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
3765192 to
ea654cb
Compare
|
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks! |
Summary:
check-for-reproducer.ymlrunscheckForReproducer.json every issue edit so that, once an author adds a reproducer, theNeeds: Reprolabel is removed. In practice the label is never removed, because the guard that is meant to defer to maintainers locks the bot out of its own label.hasMaintainerChangedLabeltreats everylabeled/unlabeledevent onNeeds: Reproas a maintainer decision unlessactor.type === 'Bot'. That only excludes GitHub Apps (e.g.github-actions[bot]).react-native-bot— the account this workflow runs as viaREACT_NATIVE_BOT_GITHUB_TOKEN— is a regular user account, so its timeline events haveactor.type === 'User'. The bot's own initial "labeled Needs: Repro" event therefore satisfiesactor.login !== author && label.name === 'Needs: Repro', the function returnstrue, and every subsequent run exits before looking for a reproducer.Concrete example, #58427 (timeline via the REST API):
The author edited a same-account GitHub repository link (created from
react-native-community/reproducer-react-native) into the body;check-for-reproducerran on each edit (runs 34381378212 and 34381697572, both green) and the label stayed. A sample of the 8 most recently updated open issues carryingNeeds: Reproshows the same shape on all of them: the onlyNeeds: Reproevent is the bot's ownlabeled, with no removal ever recorded, and none of 12 recently closedNeeds: Reproissues had the label removed by the bot either.This PR makes
hasMaintainerChangedLabelignore events produced byreact-native-botin addition to GitHub Apps, so that only human label changes count as maintainer intervention. It adds a unit test for the script (there was none), covering: no reproducer → labels added; author repo link → label removed; bot-applied label + author edit → label removed (the regression); maintainer changed the label → no-op; unrelated label changes ignored; reproducer in a comment by its author.Changelog:
[INTERNAL] [FIXED] - Let
check-for-reproducerremoveNeeds: Reproafter the author adds a reproducer (the bot's own label no longer counts as a maintainer decision)Test Plan:
With the script reverted to
main, the three tests whose timeline contains the bot's ownlabeled Needs: Reproevent fail (3 failed, 3 passed) becausehasMaintainerChangedLabelreturnstrue, confirming the test captures the regression.prettier --check(3.9.4, repo config) passes on both files.