Split CI into nightly + release + PR-check, mirror darktable's branching

[andriiryzhkov]

Replaces the single build-models.yml with three focused workflows and adopts darktable's own release/branching pattern so the model set can be maintained the same way the host app is.

What's changing

File	Triggers	Publishes to
nightly.yml	push: master (paths-filtered), manual dispatch	rolling nightly-X.Y.Z pre-release
release.yml	release-X.Y.Z[.N] tag push, manual dispatch	tag-named release (draft for review)
check-pr.yml	PRs to master or models-*.x, manual dispatch	nothing – validates only

Replaces build-models.yml and renames check-models.yml → check-pr.yml.

Tag convention – even = release, odd = dev anchor

This PR adopts a parity-based split for release-* tags:

• Even minor, 4 components (release-5.6.0.1, release-5.6.0.2, release-5.8.0.1, …) – real model releases. The 4th component is a per-darktable-line revision counter: release-5.6.0.1 is the first model set for darktable 5.6.0, release-5.6.0.2 is the next revision for the same darktable line, etc. Tag pushes trigger release.yml → matrix build → draft upload.
• Odd minor, 3 components (release-5.5.0, release-5.7.0, …) – development anchors. release.yml's tag filter excludes these, so pushing them creates the tag silently with no workflow side effects. They exist solely to give git describe an anchor for the nightly version label.

tools/get_git_version_string.sh matches the whole release-* namespace, so both kinds contribute to the version computation. The nightly title reads "X.Y.Z+N~gXXX" relative to the closest reachable tag, whether that's a real release or a dev anchor.

Add a seed dev anchor

The repo has no release-* tag at all yet. git describe falls back to a bare commit hash, so the nightly title would read "nightly models 81b7b63" instead of a version. Push a dev anchor from current master:

git checkout master
git pull
git tag -a release-5.5.0 -m "dev anchor for the 5.6.0 development cycle"
git push origin release-5.5.0

Order doesn't matter (before or after merging this PR) – release-5.5.0 has an odd minor, so release.yml's tag filter ignores it either way. The label flips to "5.6.0.1" the moment the real release-5.6.0.1 is tagged.

Future dev anchors (release-5.7.0, release-5.9.0, …) can be added the same way during their respective dev cycles, also without workflow side effects.

Behavior contracts

• Strict publish guard on both nightly and release. A single failing matrix member blocks the publish step. No partial releases, no silently missing models. (needs.build.result == 'success')
• Tag-triggered releases land as drafts. The maintainer reviews the artifacts and RELEASE_NOTES.md content, then clicks Publish. Removes the "released by accident" failure mode.
• Defensive draft on nightly. If someone manually dispatches nightly.yml against a tag ref (rare, but possible from the Actions UI), the upload becomes a draft instead of clobbering the public rolling nightly.
• Coalesced rapid pushes. Nightly uses concurrency: { group: nightly, cancel-in-progress: true } so 3 PRs merged in 2 minutes produce 1 nightly run with the latest commit, not 3 racing runs. Same per-PR for check-pr.yml.
• uv cache enabled on every workflow. Shared cache keyed on uv.lock – first run after a lockfile change pays the full download cost, every run after that is a fast restore. Saves meaningful CI time across the matrix.

What a maintainer no longer does

Old flow (build-models.yml): the workflow triggered on release: types: [published]. So every time anything new should reach users, the maintainer had to manually create a release in the GitHub UI to fire the build. This conflated "I just merged a PR" with "I want to ship a release", and meant master commits without a manual release attached produced no artifacts at all.

New flow:

• Merges to master automatically trigger nightly.yml. The rolling nightly pre-release is updated in place – no maintainer action needed. Users tracking nightly always have the latest builds.
• Real releases are tagged events. The maintainer creates a release-X.Y.Z tag when they decide to ship, and release.yml builds + uploads a draft. The maintainer reviews the draft and publishes from the UI.

The two concerns are now decoupled. Merging a PR no longer requires any release-creation step; tagging a release no longer requires anything except git tag + git push.

What a maintainer does

Cutting the first model release for darktable 5.6.0:

git tag release-5.6.0.1
git push origin release-5.6.0.1
# release.yml builds, uploads draft, you review and publish

git branch models-5.6.x release-5.6.0.1
git push origin models-5.6.x
# .x branch ready for subsequent revisions

For the next revision (release-5.6.0.2):

1. PR fix against models-5.6.x (check-pr.yml validates).
2. Merge.
3. git tag release-5.6.0.2 from the merge commit on models-5.6.x, push.
4. release.yml builds, uploads draft, review, publish.

What's not changing

• The matrix structure inside each workflow (discover → build → publish).
• The per-model build steps (dtai setup → convert → validate → package / demo).
• The .dtmodel artifact format or upload location.
• darktable's data/ai_models.json registry – it continues to point at GitHub release assets by name.

Open items (not in this PR)

• Nightly version label uses git describe against this repo's own release-* tags. Before the first release tag exists it shows a bare commit hash; flips to a proper "X.Y.Z+N~gXXX" form once tags appear.

[andriiryzhkov]

Tested on a brand new test repository. Made some small improvements.

[TurboGit]

Thanks!