[mvallebr]

Changes

• Keep CI in this source repository using normal GITHUB_TOKEN; PR CI uses example-self-hosted-saas-app-pr and loopback per-job rootless BuildKit with read-only contents and no publication, version allocation, registry cache writes, or Kubernetes API access.
• Publish on example-self-hosted-saas-app-main with shared BuildKit, infrastructure-mounted Harbor auth, existing image/cache targets, and one serialized automatic/manual publication queue.
• Manual main dispatch validates an existing canonical semver tag as image version only, builds fixed main source, and creates no source tag. PR-number concurrency cancels superseded checks.
• Update existing README with runner routing, public outside-contributor approval before first self-hosted run, and trusted-cluster-execution limitations. Labels/namespaces are not authorization boundaries.

Evidence and limitations

Parent verified all nine workflows against the GitHub Actions schema and exercised 24 actual version/tag Bash and Git consumer cases using file-only remotes, plus canonical-leading-zero rejection cases for both example/MyPics workflows. Independent app review round two scored 9 with no findings. No product image build or live-cluster/CNI test was performed.

Rollout dependency

Do not merge app routing before infrastructure PR humansoftware/self-host-saas-k3s#23 and human cutover PR humansoftware/human_infra#24 are merged and the infrastructure is applied. New-label CI may queue until that deployment. This PR does not merge or apply cluster changes.

[mvallebr]

Follow-up review pass — corrections applied

A further independent review of this PR found and I applied:

• Non-main manual dispatch no longer silently does nothing. Before, a manual run from a non-main branch matched neither job and finished green with zero jobs. The CI job now also runs for workflow_dispatch on any non-main ref, on the <project>-pr pool with rootless loopback BuildKit and no publication, cache write, tag write or Secret read.
• Job display names are consistent with the CI / Publish convention used across the repositories.
• One unused step identifier was removed.

Verification after the correction

• All nine changed workflow heads parse and every job declares its pool and guard.
• Sixteen real version/tag consumer cases passed against file-only local Git remotes: tagless history, existing canonical version rebuild without creating a source tag, injection-shaped input rejected, leading-zero versions rejected, and the source HEAD never changes. No product image build or cluster interaction was performed.

One thing to do during rollout

This PR renames the PR-facing job, so if the repository's branch protection lists the old job name as a required status check, update it at merge time or pull requests will sit waiting for a check that never reports. The infrastructure PR documents this.

Workflows in this repository remain the single place these pipelines are defined; runners are provisioned by the infrastructure PR and must be applied before merging.

[mvallebr]

Second review pass — findings applied

An independent review of this PR (and its siblings) found three issues, all fixed here:

• A push could publish the wrong commit. The publication checkout pinned ref: main, so a serialized run waiting behind another would resolve to whatever main pointed at when it finally started: it would build the newer commit under a version derived from the older one, leaving the original commit without its own image. Publication now checks out main for manual rebuilds and github.sha for pushes, so a push always builds exactly the commit that triggered it.
• Manual non-main builds cancelled each other. The PR concurrency group used github.event.pull_request.number, which is empty for a manual dispatch, so every non-main manual build shared one group with cancel-in-progress: true. The group now falls back to github.ref.
• The non-main manual path was undocumented. Dispatching from a non-main branch runs CI on the -pr pool and ignores the tag input; the README now says so, including that GitHub still requires a value because the input is declared required.

Verification after the corrections

Both workflow heads parse; the publication checkout expression and the concurrency group were asserted directly, and the job guards still route pull_request and non-main manual runs to the -pr pool while publication stays limited to push-main and manual-main.

Not verified here: real runner delivery, registry access, and whether queue: max is enabled for this repository's plan. The reviewer confirmed neither repository has branch protection requiring the old job names, so the CI/Publish rename breaks no required check.

Runner provisioning must be applied from the infrastructure PR before this workflow routing is merged.