Build-scan-promote pipeline: explicit trivy-scan, podman-promote, deploy-prod actions

- podman-build-publish: reverted to pure build+push (v8 behavior) — the Trivy gate briefly embedded in v10 moves to an explicit action instead. - trivy-scan (new): scans a registry image ref, fails on fixable HIGH/CRITICAL findings; jobs pin it to amd64 runners. - podman-promote (new): server-side retag via skopeo copy --all — releases promote the scanned sha-<commit> candidate instead of rebuilding. - deploy-prod (new): shared deploy body for the *.podman repos (with the BatchMode/IdentitiesOnly ssh flags only two of the four copies had). - README: documents the standard build.yml/release.yml pipeline; refs standardized on public/actions. Plan: noctrl.podman tmp/WORKFLOW_REWRITE_PLAN.md. Release as v11. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01P5NjXQ3jmyVjimHQxnyKhg
2026-08-29 13:40:46 +02:00
1 parent 2e0291a757
commit 0807dc6434
@@ -2,54 +2,132 @@

 Reusable Gitea Actions composite workflows for noctrl infrastructure automation.

+## The standard pipeline (since v11)
+
+Build once, scan explicitly, promote — the registry is the hand-off between
+workflows. A push to the default branch builds each architecture exactly once
+and pushes immutable, never-deployed candidate tags (`sha-<commit>[-<arch>]`);
+an explicit Trivy job scans the candidate. A release rebuilds nothing: it
+re-scans the candidate and retags it server-side.
+
+`build.yml` (push to default branch):
+
+```
+validate (pre-commit)  →  build-amd64 ─┐
+                          build-arm64 ─┤→  manifest (multi-arch only)  →  scan
+```
+
+`release.yml` (tag `v*`):
+
+```
+scan (candidate of the tagged commit)  →  promote (sha-<commit> → vX)
+```
+
+The scan in `release.yml` is the enforcing gate: a release tag can only come
+into existence behind a scan that passed at promotion time. Candidates carrying
+CVEs may exist in the registry — nothing consumes `sha-*` tags, so they are
+inert. Scan and promote jobs always run on `linux,build,amd64` (never on the
+slow arm runners; vulnerability results are package-based and arch-independent).
+
+Before v11, `podman-build-publish@v10` briefly embedded the Trivy gate itself;
+v11 moved it into the explicit `trivy-scan` action.
+
 ## Available Actions

 ### Podman Build And Publish

-Builds and optionally pushes OCI container images to `registry.noctrl.eu` using Podman with isolated storage context.
-
-Since `v10`, the built image is scanned with Trivy before the push and the action fails on fixable HIGH/CRITICAL vulnerabilities (tune with `scan-severity`, opt out with `scan: "false"`). Requires the `trivy` binary on the runner (present in `noctrl/gitea-runner` since `v9`).
+Builds and optionally pushes OCI container images to `registry.noctrl.eu` using
+Podman with isolated storage context. Build and candidate-push are deliberately
+one action: each invocation initializes its own podman storage, so a split
+build/push pair would have to re-pull what was just built.

 **Location:** [`./podman-build-publish`](./podman-build-publish)

-**Use in workflows:**
 ```yaml
- uses: https://gitea.noctrl.eu/noctrl/actions/podman-build-publish@v1
+- uses: https://gitea.noctrl.eu/public/actions/podman-build-publish@v11
  with:
    image-name: noctrl/myapp
    tags: |
-      latest
-      sha-${{ github.sha }}
+      sha-${{ github.sha }}-amd64
+    registry-username: ${{ secrets.REGISTRY_USERNAME }}
+    registry-password: ${{ secrets.REGISTRY_PASSWORD }}
 ```

-See [podman-build-publish README](./podman-build-publish/README.md) for full documentation.
-
 ### Podman Manifest Publish

-Creates and pushes OCI multi-arch manifest tags to `registry.noctrl.eu` using
-Podman with isolated storage context.
+Creates and pushes OCI multi-arch manifest tags to `registry.noctrl.eu` —
+used to assemble the per-arch candidates into the multi-arch candidate.

 **Location:** [`./podman-manifest-publish`](./podman-manifest-publish)

-**Use in workflows:**
 ```yaml
- uses: https://gitea.noctrl.eu/noctrl/actions/podman-manifest-publish@v1
+- uses: https://gitea.noctrl.eu/public/actions/podman-manifest-publish@v11
  with:
    image-name: noctrl/myapp
-    manifest-tag: v1.2.3
+    manifest-tag: sha-${{ github.sha }}
    source-tags: |
-      v1.2.3-tmp-123-amd64
-      v1.2.3-tmp-123-arm64
+      sha-${{ github.sha }}-amd64
+      sha-${{ github.sha }}-arm64
 ```

-See [podman-manifest-publish README](./podman-manifest-publish/README.md) for full documentation.
+### Trivy Scan
+
+Scans an image ref in `registry.noctrl.eu` and fails on fixable HIGH/CRITICAL
+vulnerabilities (severities configurable). Requires `trivy` on the runner
+(`noctrl/gitea-runner` >= v9). Pin the job to `linux,build,amd64`.
+
+**Location:** [`./trivy-scan`](./trivy-scan)
+
+```yaml
+- uses: https://gitea.noctrl.eu/public/actions/trivy-scan@v11
+  with:
+    image-name: noctrl/myapp
+    tag: sha-${{ github.sha }}
+    registry-username: ${{ secrets.REGISTRY_USERNAME }}
+    registry-password: ${{ secrets.REGISTRY_PASSWORD }}
+```
+
+### Podman Promote
+
+Retags an existing image (or multi-arch manifest list) server-side via
+`skopeo copy --all` — no rebuild, no transfer, fails if the source tag does not
+exist. Requires `skopeo` on the runner (`noctrl/gitea-runner` >= v10).
+
+**Location:** [`./podman-promote`](./podman-promote)
+
+```yaml
+- uses: https://gitea.noctrl.eu/public/actions/podman-promote@v11
+  with:
+    image-name: noctrl/myapp
+    source-tag: sha-${{ github.sha }}
+    target-tag: ${{ github.ref_name }}
+    registry-username: ${{ secrets.REGISTRY_USERNAME }}
+    registry-password: ${{ secrets.REGISTRY_PASSWORD }}
+```
+
+### Deploy Prod
+
+Shared deploy body for the `*.podman` infrastructure repos: installs the SSH
+deploy key, validates the mounted deploy-target env file, and pipes the deploy
+runner's `deploy-prod.sh` to the production host over SSH. Runs on that host's
+dedicated deploy runner (`gitea-runner-deploy` image).
+
+**Location:** [`./deploy-prod`](./deploy-prod)
+
+```yaml
+- uses: https://gitea.noctrl.eu/public/actions/deploy-prod@v11
+  with:
+    deploy-target-file: /run/noctrl/prod-deploy-target.env
+    ssh-key-b64: ${{ secrets.PROD_DEPLOY_SSH_KEY }}
+    target-sha: ${{ github.sha }}
+```

 ## Usage

 Reference actions by absolute URL in your workflow:

 ```yaml
- uses: https://gitea.noctrl.eu/noctrl/actions/<action-name>@<ref>
+- uses: https://gitea.noctrl.eu/public/actions/<action-name>@<ref>
 ```

 **Ref Options:**
@@ -63,6 +141,7 @@ Actions reference caller repository secrets. Ensure your repository has required

 - **REGISTRY_USERNAME** — registry.noctrl.eu authentication username
 - **REGISTRY_PASSWORD** — registry.noctrl.eu authentication password
+- **PROD_DEPLOY_SSH_KEY** — base64-encoded SSH deploy key (`*.podman` repos only)

 Set these in repository **Settings** → **Secrets**.

@@ -71,6 +150,5 @@ Set these in repository **Settings** → **Secrets**.
 When adding new actions:
 1. Create action directory: `./action-name/`
 2. Include `action.yaml` (composite action definition)
-3. Include `README.md` with inputs, outputs, and usage example
-4. Tag stable versions: `git tag v1`, `git tag v2`, etc.
-5. Update this root README
+3. Tag stable versions: `git tag v1`, `git tag v2`, etc.
+4. Update this root README