Disable reopen wontfix

[kzhou314]

Closes https://github.com/github/accessibility/issues/10756.

Closing a scanner-filed issue without merging a fix used to cause it to reopen on the next run. Adding the wontfix label now keeps it closed

[Copilot]

Pull request overview

This PR updates the “file” GitHub Action so that previously-closed scanner-filed issues are not reopened on subsequent runs when the issue is labeled wontfix, and documents the behavior for users.

Changes:

• Add isWontfixIssue() helper and integrate it into the repeated-filing (reopen) path so wontfix issues stay closed.
• Add Vitest coverage for the new label-check behavior, plus regression adjustments to existing tests.
• Document how to keep an issue closed using the wontfix label.

Show a summary per file

File	Description
README.md	Documents the wontfix label behavior for preventing reopen.
.github/actions/file/src/index.ts	Skips reopening repeated filings when the issue is labeled wontfix.
.github/actions/file/src/isWontfixIssue.ts	New helper to fetch issue labels and detect wontfix.
.github/actions/file/tests/wontfixReopen.test.ts	New end-to-end-ish test ensuring wontfix issues are not reopened.
.github/actions/file/tests/isWontfixIssue.test.ts	Unit tests for label detection and request routing.
.github/actions/file/tests/dryRun.test.ts	Updates regression guard to account for the new label-check GET request when not in dry-run.

Copilot's findings

Tip

Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

• Files reviewed: 6/6 changed files
• Comments generated: 1

[JoyceZhu]

if TS will let you do this, shoving these labels/label names in a set so the containment check is constant time would be nice. (some repos / organizations really pile on the labels!)

[kzhou314]

That makes sense! Correct me if I'm wrong, but I thought converting an array to a set in TS would be O(n) time, which would asymptotically be the same as iterating through the array to find the correct label. Since we only do a single containment check here, I'm not sure if the set has much benefit.

[JoyceZhu]

it's basically O(n) vs O(n) + O(n) simplifying to O(n) but you go through twice, and that'll further scale per-filing since I believe this is called in an outer loop for every filing

[JoyceZhu]

I was thinking about naming here; it might be more maintainable to call isWontfixIssue a more generic shouldReopenIssue or something similar. The latter expresses the intent of this feature more broadly. Right now its implementation is totally coupled to the existence of a wontfix label, but e.g. if we add other supported labels or change the fingerprinting algorithm (deciding if a finding is effectively a duplicate of another one), there won't be logic unrelated to wontfix at all also buried inside isWontfixIssue.

[JoyceZhu]

🤔 I wonder if instead of making one API request per issue, it would work to attempt to grab all wontfix issue IDs in the repository in a single request (based on these docs we'd need to say "issues with a closed state and the label wontfix"), then we can just do a quick set check.

Another possibility: the repository in question may not even have wontfix as a possible label, in which case we're unnecessarily sending additional network traffic. Perhaps checking if the label even exists for the repository could help us avoid continuing with requests which won't do anything.