Add [skip publish] and [skip github-pages] markers (finer-grained than [skip ci])

[thorwhalen]

Ask

[skip ci] is all-or-nothing: it skips validation, publishing and Pages together. Add two narrower markers that compose on top of it:

• [skip publish] — run everything, but do not release to PyPI.
• [skip github-pages] — run everything, but do not push to gh-pages.

[skip ci] keeps its current meaning: skip everything.

Why

The two side-effecting jobs are exactly the ones you sometimes want to suppress without losing the signal from the ones you don't:

• A docs-only or comment-only change on the default branch: you want tests to run, you don't want to burn a PyPI version number. Today the only lever is [skip ci], which throws away the test run too — so the choice is "release something trivial" or "test nothing".
• A change that touches the docs build itself, or a repo whose Pages deploy is noisy: same shape.
• Landing several commits in quick succession where only the last should publish.

PyPI version numbers are permanently burned once used, so "release fewer accidental versions" has real value, and today the only way to get it also costs you CI.

Shape of the change

The machinery already exists — [tool.wads.ci.publish].skip_ci_marker / publish_marker are read into setup outputs and consumed by the publish job's if:. So this is the same pattern, one more marker each:

# publish job
if: "!contains(github.event.head_commit.message, needs.setup.outputs.skip-ci-marker)
     && !contains(github.event.head_commit.message, '[skip publish]')
     && github.ref == format('refs/heads/{0}', github.event.repository.default_branch)
     && (needs.setup.outputs.publish-enabled == 'true' || contains(github.event.head_commit.message, needs.setup.outputs.publish-marker))"

# github-pages job
if: "!contains(github.event.head_commit.message, '[skip ci]')
     && !contains(github.event.head_commit.message, '[skip github-pages]')
     && github.ref == format('refs/heads/{0}', github.event.repository.default_branch)
     && needs.setup.outputs.docs-enabled != 'false'"

Ideally configurable the way the existing ones are, e.g. [tool.wads.ci.publish].skip_publish_marker and [tool.wads.ci.docs].skip_marker, defaulting to [skip publish] / [skip github-pages] — so the literals aren't hard-coded and a repo can rename them.

Both templates need it (uv-ci.yml reusable + github_ci_uv.yml inline), plus a line each in the CI-config reference so the markers are discoverable.

Note on the publish job's existing condition

Worth deciding as part of this: publish currently gates on skip-ci-marker (configurable) while github-pages hard-codes '[skip ci]'. If skip_ci_marker is ever set to something non-default, the two jobs disagree about what "skip" means. Making them consistent would fold naturally into this change.

[thorwhalen]

A note from the on-demand CI work (#85, #86), for whoever picks this up.

These markers can land without touching any caller stub: add them to the setup outputs and the job if:s, as #86 did for the trigger. Two cautions:

1. Guard each new clause against an empty output: (needs.setup.outputs.X != '' && contains(needs.setup.outputs.commit-subject, needs.setup.outputs.X)). read-ci-config installs wads from PyPI, while uv-ci.yml@master goes live at merge. Until the release that emits the new output reaches PyPI, the output is empty. An unguarded !contains(subject, '') would then likely skip publish on every repo, including the wads release that ships the output.
2. The marker clauses are now repeated across four job if:s, in both uv-ci.yml and the inline template. Consider computing run-validation / run-publish / run-pages once, in a bash step of the setup job, and gating each job on == 'true'. That logic lives inside the workflow, so it doesn't wait for a PyPI release, and the next marker becomes a one-place change.

[thorwhalen]

Triage / plan

Agree with the issue's own proposed shape: add `[skip publish]` / `[skip github-pages]` markers that compose on top of (not replace) `[skip ci]`, each independently configurable via `[tool.wads.ci.publish].skip_publish_marker` / `[tool.wads.ci.docs].skip_marker` mirroring the existing `skip_ci_marker`/`publish_marker` pattern, plus folding in the noted `publish`-vs-`github-pages` marker-name inconsistency fix.

Not implementing in this pass -- touches both CI templates (`uv-ci.yml` reusable workflow + inline `github_ci_uv.yml` mirror) and is a live-workflow-conditional change (the reusable workflow is what every wads-managed repo's next default-branch push runs), so it needs the same care as #91/#56: get the `if:` conditions exactly right in both places, plus a docs line, plus tests. Time-boxed this triage pass toward several smaller independent fixes (landed: #90, #75, #57, #58, and #59's easier half) rather than one larger one; this is next in line if time remains, otherwise it's ready to pick up as-is -- the plan above is the whole design, no further decision needed from you.

[thorwhalen]

Cloud sweep (PR #99): not implemented there, and labelled needs-local.

Why: this changes the job if: conditions of the reusable workflow that every repo on @master runs as soon as it merges, and the cloud VM cannot execute GitHub Actions expressions. The only tests possible here are YAML-shape tests, which would not catch a wrong contains() or an empty-output edge case. The empty-output hazard from the earlier comment is real: read-ci-config installs wads from PyPI, so a new output is empty until the release carrying it is published, while uv-ci.yml@master changes go live at merge.

Concrete plan for a local session:

1. In the setup job of .github/workflows/uv-ci.yml (and the mirror wads/data/github_ci_uv.yml), add one bash step that computes run-publish and run-pages from the commit subject, using literal default markers when the config outputs are empty. Gate publish and github-pages on == 'true', so later markers become a one-place change.
2. Add [tool.wads.ci.publish].skip_publish_marker and [tool.wads.ci.docs].skip_marker to CIConfig and read_ci_config.py, and make github-pages use the configurable skip-ci marker instead of the literal.
3. Unit-test the bash step the way test_git_commit_push_retry.py tests the push step: extract it from the YAML and run it under bash with fake subjects.
4. Verify on a scratch repo pinned to the branch: plain, skip-publish, skip-pages, and skip-ci commits on the default branch. Then merge.

---

Generated by Claude Code