Files
actions/README.md
T
peetandClaude Fable 5 0807dc6434 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

155 lines
5.0 KiB
Markdown

# Gitea Actions
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. 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)
```yaml
- uses: https://gitea.noctrl.eu/public/actions/podman-build-publish@v11
with:
image-name: noctrl/myapp
tags: |
sha-${{ github.sha }}-amd64
registry-username: ${{ secrets.REGISTRY_USERNAME }}
registry-password: ${{ secrets.REGISTRY_PASSWORD }}
```
### Podman Manifest Publish
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)
```yaml
- uses: https://gitea.noctrl.eu/public/actions/podman-manifest-publish@v11
with:
image-name: noctrl/myapp
manifest-tag: sha-${{ github.sha }}
source-tags: |
sha-${{ github.sha }}-amd64
sha-${{ github.sha }}-arm64
```
### 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/public/actions/<action-name>@<ref>
```
**Ref Options:**
- `@v1` — points to tag `v1`
- `@main` — points to default branch
- `@commit-sha` — points to specific commit
## Repository Secrets
Actions reference caller repository secrets. Ensure your repository has required secrets defined:
- **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**.
## Contributing
When adding new actions:
1. Create action directory: `./action-name/`
2. Include `action.yaml` (composite action definition)
3. Tag stable versions: `git tag v1`, `git tag v2`, etc.
4. Update this root README