4 ms·
> Does the "required status check" thing apply to `git push`, or just to the merge button on the website? It applies to all ways of updating git: push, the web
by bhuga 11y ago
> Does the "required status check" thing apply to `git push`, or just to the merge button on the website?
It applies to all ways of updating git: push, the web UI, merging, and the API.
> how do you trigger a status check to run on your actual merge/rebase as made in your local client, which will almost certainly differ in SHA1 and may differ in content from the merge made in the PR?
If they differ in SHA1 but not content, things will work fine. A protected branch cannot be updated to a git tree that has not been tested.
If your PR differs in content, clicking the 'update branch' button on a PR will make the merge commit and your PR's content the same, so a new CI run will apply to the correct content.
- geofft 11y agoThanks! That's a very sensible model. I suppose it means that the status-check API can't be used to check that the history of a branch is up to some standards, like commit messages following a style or all commits in history passing some check, but that's fine. (It is a bit at odds with the documentation of the status-check API, which implies that it's about refs, not trees.)
- bhuga 11y agoThe API was originally about SHAs, rather than refs, but for protecting branches trees make sense. (You can retrieve statuses by ref, but are required to set them by SHA). Since a SHA can be uniquely resolved to a tree, we're doing this under the hood rather than make a breaking API change. It also just makes more sense; nobody thinks in terms of trees day-to-day. Thanks for you comments about per-commit linting. We'll give them some thought.