Don't block merges on linkcheck

[woodruffw]

I believe this was an oversight in #2035 -- it doesn't make sense to allow linkchecks to pass PR gates, only to bounce them at the merge group.

---

📚 Documentation preview 📚: https://python-packaging-user-guide--2128.org.readthedocs.build/en/2128/

[woodruffw]

I had to widen this to non-main pushes as well, since first-party PRs will also trigger this since they receive the push event.

[webknjaz]

since first-party PRs will also trigger this since they receive the push event.

Not sure we really need to care about pushes, though. What fails is merge queue events.

[woodruffw]

since first-party PRs will also trigger this since they receive the push event.

Not sure we really need to care about pushes, though. What fails is merge queue events.

FWICT the merge queue only becomes available after the push-triggered checks succeed, since the linkcheck is marked as required on that trigger still.

[webknjaz]

@woodruffw no, all GH platform events are independent, they all are happening in isolated contexts and don't know of each other. But if a PR is created from within upstream, sure, both events will happen upstream and cause runs in the same repo. This means they'll create Checks API statuses that will show up in the PR. But this only highlights a repo configuration problem — we should never create topic branches upstream in the first place 🤷‍♂️. If I had enough privileges in the repo, I'd set up branch rulesets to reflect this but I don't.. Maybe one day I'll finally get to catch @pradyunsg and we'll set this up.

I don't think we should be permissive with pushes.

Meanwhile, #2129 will fix the broken links, unblocking other merges.

[woodruffw]

no, all GH platform events are independent, they all are happening in isolated contexts and don't know of each other.

Yeah, I'm not saying they're dependent. I'm saying that the "required" state is set for Test / check, and on push that was causing a failure despite essentially being a duplicate run of pull_request.

we should never create topic branches upstream in the first place

Sorry, I don't follow -- you're saying we should only ever do PRs from forks for this repo?

(As before, I'm generally agnostic on how things get accomplished. But the linkcheck continues to be a significant drag on this repo's velocity.)