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.)

[woodruffw]

@webknjaz LMK what you think of the above -- this is still functionally blocking PR merges for me.

[pradyunsg]

Let's do this. I do think we need to do a good job of keeping links up to date, but having it block PR merges does make it much slower to make unrelated to broken link changes when there's flakiness in interacting with other internet hosts. 😅

[webknjaz]

I would still not bother with the pushes but fine, I suppose..

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

Yep. We really should set up rulesets to disallow upstream branches tho. I even have JSON exports for that ready to use, btw.

[woodruffw]

Yeah, I'd be okay with going back to using my fork. IIRC the reason I switched to doing 1p branches is because of GitHub's limitations around maintainer pushes on org forks 🙂