Branch and tag protection is active: what it changes, and one check I cannot run myself

[SlavaSexton]

Both your pull requests are merged, main is green, and branch and tag protection are now active. This is what
changed for day-to-day work, and one thing I would like you to verify, because I could not.

What is protected

main now requires a pull request. One approving review from a code owner, which .github/CODEOWNERS
sets to me for every path. Stale approvals are dismissed when new commits land, the last push has to be
approved by someone other than whoever pushed it, and docker-tests must pass with the branch up to date.
Force pushes and deletion are blocked.

Tags matching v* cannot be created, deleted or moved. A release needs a tag, so this is what keeps
version releases going out deliberately rather than by accident. Drafts are unaffected.

Nothing here changes how you have been working: branch, pull request, review, merge. It only makes that the
only route.

The part I could not test

Repository admins are on the bypass list, so when I tried pushing straight to main to check the rule, GitHub
printed the warnings and let it through anyway. That proves the rule is loaded, not that it refuses anyone.
Since you hold write and are not on that list, the same push from your side should be rejected outright.

If you have a spare minute: commit something harmless on main locally and try to push it. Expected result is
a rejection naming the pull request requirement, with nothing reaching the remote. If it goes through instead,
say so here, because that would mean the rule is not doing what it claims and I would rather learn it from a
one-line test than from a surprise later.

On the two merges

Both were mine to fix and you fixed them.

The resolver test used D:\shots\out as its example of an absolute path, which os.path.isabs calls absolute
on Windows and relative on Linux, so the container read a correct resolver as a failure. docker-tests was
red from 06:46 through five of my pushes and I did not notice, because I kept reading the local run instead.
The assertion you added, that the test's own example is absolute on the platform running it, is the part that
stops this recurring.

The hardcoded node count in three files was the same class of thing: three copies of a number that only one
place should own. Reading it from len(OCIO_NODE_CLASSES) is right.

And the README input list you corrected in #8 was a section I rewrote around it yesterday and never came back
to, so it still advertised four still formats and six codecs.

[JoeGaffney]

Nice yes best to avoid commiting to main unless small hotfix and squash merge from feature branch in a pull request.

[AndreiOrehov]

Ran it. The rule holds against a write-level account — rejected outright, nothing reached the remote.

Empty commit on top of 70f6765, so that even an unexpected success could not change a byte of main:

$ git commit --allow-empty -m "probe: direct push to main from a write-level account"
$ git push origin main
remote: error: GH013: Repository rule violations found for refs/heads/main.
remote:
remote: - Changes must be made through a pull request.
remote:
remote: - Required status check "docker-tests" is expected.
remote:
 ! [remote rejected] main -> main (push declined due to repository rule violations)
error: failed to push some refs to 'https://github.com/SlavaSexton/ComfyUI-OCIO.git'

main is still at 70f6765 — confirmed against the API afterwards, not just locally. Local probe commit
discarded.

Both required checks are named in the refusal, which is the useful part: the message tells you what to do
next rather than just saying no.

I did not test tag protection — creating a v* tag to watch it fail felt like the wrong thing to try on a
repository where a tag means a release. Say the word and I will, or leave it; the branch result at least
proves rules are enforced for non-bypass accounts.