fix(frontend): pin rc4 image and repair dependency automation

[bussyjd]

Summary

Pins the embedded frontend Helm values to the rc4 frontend image and repairs the dependency automation that should have opened this bump automatically:

• obolnetwork/obol-stack-front-end:v0.1.25-rc4@sha256:143633300757bec467a8818aa8aa99ec30d70f5096ffe4a075e66b6adc6014a0
• Keeps the human-readable rc4 tag while making the multi-arch index digest authoritative.
• Moves the frontend Renovate custom manager from GitHub releases to the Docker datasource.
• Teaches Renovate to capture the deployed tag@sha256 shape and keep the digest fresh with pinDigests.
• Fixes the Renovate workflow action pin, tells Renovate which repository/base branch to process, and removes invalid per-package every hour schedules; the workflow itself now runs hourly.
• Updates all workflow uses: actions to the current upstream semver tag commit SHA.
• Adds SHA-256 verification for the direct gitleaks GitHub release tarball download.

Architectural impact

The stack was still deploying the rc1 frontend artifact from embedded values. That means a fresh obol stack up could install a CLI/backend rc4 stack while the UI stayed on rc1 bits.

flowchart LR
    A["obol stack up"] --> B["Embedded helmfile values"]
    B --> C["obol-frontend Helm release"]
    C --> D["Frontend image reference"]
    D --> E["Docker registry multi-arch index digest"]
    E --> F["linux/amd64 manifest"]
    E --> G["linux/arm64 manifest"]

Loading

With this change, the deployment path stays the same, but the selected artifact moves from rc1 to rc4:

flowchart TD
    Before["Before: v0.1.25-rc1@sha256:e7b38..."] --> Problem["Frontend can lag stack release candidate"]
    After["After: v0.1.25-rc4@sha256:143633..."] --> Result["Frontend matches rc4 release candidate"]

Loading

No migration script or upgrade wrapper is needed; existing upgrades naturally converge through the normal Helm release values on the next stack apply.

Why Renovate missed this

There were multiple separate blockers:

flowchart TD
    Start["Scheduled Renovate workflow"] --> BrokenAction["Broken action SHA"]
    BrokenAction --> Stop1["Workflow failed before Renovate started"]
    Start --> MissingRepo["No RENOVATE_REPOSITORIES"]
    MissingRepo --> Stop2["Renovate would start but find no repository to scan"]
    Start --> Config["Renovate config"]
    Config --> BadSchedule["Invalid schedule: every hour"]
    BadSchedule --> Stop3["Config validation failure on current Renovate"]
    Config --> OldFrontendRule["Frontend rule used GitHub releases + bare tag regex"]
    OldFrontendRule --> Miss["Did not match Docker pin: v0.1.25-rcN@sha256:..."]

Loading

The corrected path is:

flowchart LR
    Workflow["Hourly Renovate workflow"] --> Action["renovatebot/github-action pinned to latest tag SHA"]
    Action --> Repo["RENOVATE_REPOSITORIES=ObolNetwork/obol-stack"]
    Repo --> Validator["Valid renovate.json"]
    Validator --> Manager["custom.regex Docker manager"]
    Manager --> Current["currentValue=v0.1.25-rc4"]
    Manager --> Digest["currentDigest=sha256:143633..."]
    Manager --> Registry["Docker datasource: obolnetwork/obol-stack-front-end"]
    Registry --> PR["Future rc tag + digest bump PR"]

Loading

GitHub Actions pin audit

Before this PR, every uses: entry was commit-SHA pinned, but many were not on the latest upstream semver tag SHA. The workflow set was updated to the current live tags for:

• actions/checkout v6.0.2
• actions/setup-go v6.4.0
• actions/setup-python v6.2.0
• actions/upload-artifact v7.0.1
• actions/download-artifact v8.0.1
• azure/setup-helm v5.0.0
• Docker actions: setup-buildx v4.1.0, setup-qemu v4.0.0, login v4.2.0, metadata v6.1.0, build-push v7.2.0
• aquasecurity/trivy-action v0.36.0
• github/codeql-action/upload-sarif v4.36.0
• extractions/setup-just v4.0.0
• renovatebot/github-action v46.1.14
• softprops/action-gh-release v3.0.0

helm/chart-testing-action v2.8.0 and helm/kind-action v1.14.0 were already current and remain SHA-pinned.

The direct gitleaks release download is not a GitHub Action, so it now verifies the gitleaks_8.30.1_linux_x64.tar.gz SHA-256 before installation.

Registry proof

docker buildx imagetools inspect obolnetwork/obol-stack-front-end:v0.1.25-rc4 reports multi-arch index digest:

sha256:143633300757bec467a8818aa8aa99ec30d70f5096ffe4a075e66b6adc6014a0

The tag v0.10.0-rc4 does not exist for the frontend image, so v0.1.25-rc4 is the matching frontend artifact tag.

Validation

• docker buildx imagetools inspect obolnetwork/obol-stack-front-end:v0.1.25-rc4 --format '{{.Manifest.Digest}}'
• git diff --check
• go test ./internal/embed ./internal/defaults ./internal/stack -count=1
• just generate
• jq empty renovate.json
• Frontend Renovate regex extraction returns depName=obolnetwork/obol-stack-front-end, currentValue=v0.1.25-rc4, and the expected currentDigest.
• npx --yes -p renovate renovate-config-validator renovate.json
• go run github.com/rhysd/actionlint/cmd/actionlint@latest .github/workflows/*.yml .github/workflows/*.yaml
• Workflow action audit script confirms every uses: line matches the current upstream tag SHA.
• Downloaded gitleaks_8.30.1_linux_x64.tar.gz and verified SHA-256 551f6fc83ea457d62a0d98237cbad105af8d557003051f41f3e7ca7b3f2470eb.
• gh workflow run Renovate --ref fix/frontend-rc4-image-pin -f dry_run=true reached Repository started after the workflow fixes. Branch dispatch still validates the old default-branch config until this PR merges; the branch config itself validates locally with Renovate.

Release action

Also published v0.10.0-rc3 as a non-draft GitHub pre-release so it is no longer stuck as a draft rc release.