[pre-commit.ci] pre-commit autoupdate

[pre-commit-ci]

updates:

• github.com/PyCQA/bandit: 1.8.5 → 1.8.6

[webknjaz]

@sirosen for bot PRs, you usually want to also approve them right away so that doesn't block auto-merging.

[sirosen]

Thanks for the pointer! I'm still getting used to the github merge queue and hadn't realized that "add to queue" was decoupled from approval. Makes total sense. 👍

[webknjaz]

@sirosen yea, “add to the queue” is waiting for all the protections to be passing and attempting a merge, which includes CI, any integration-based statuses (through branch protection / rulesets) and approvals.
If merging (potentially together with other PRs) failed, it can be removed from the queue, but the approvals remain intact.
The button is functionally similar to auto-merge, which is what you'd see when merge queues are not required.

This is also because branch protection may be set up to require more approvals than one.

In terms of https://gating.dev, this is “let's merge this entire thing whenever the gate lets us” vs. “one of the humans reviewing thinks that a part of the patch they care about/understand well enough is fine”, which contributes to the gate allowing merging, but is not a request to merge by itself.

It feels like GitHub's Merge Queues didn't capture all the aspects of what's possible with the idea of gating. But the portion that they did, improves the situation comparing to what was before. I think there's difficulty in terms of UX/DX to represent this all to the users without having to educate them first, hence the confusion.

See also https://graydon2.dreamwidth.org/1597.html / https://zuul-ci.org/docs/zuul/latest/gating.html.