feat: S3-backed cache-s3 siblings (golang/rust/node-pnpm) for Hetzner RGW

[mike-ainsel]

Adds -s3 sibling cache actions for the hz self-hosted runner fleet, following the existing turborepo/cache-s3 precedent.

What

• actions/golang/cache-s3
• actions/rust/cache-s3
• actions/node/cache-pnpm-s3

Each mirrors its GitHub-cache sibling (same key scheme) but uses tespkg/actions-cache (pinned to e07e2d49 = v1.10.2) against an S3 endpoint, defaulting to the Hetzner RadosGW s3.hz.platforma.bio (split-DNS → in-cluster RGW on hz, public elsewhere), bucket ci-actions-cache.

Why

On hz runners we are dropping the shared-hostPath toolchain caches (a cross-job contamination surface) and letting each job restore/save its own copy from RGW — node-local NVMe is left purely for the ephemeral per-job workdir. Caches now live in object storage exactly like the turbo cache.

Safety

• Additive only — existing golang/cache / rust/cache / node/cache-pnpm are untouched, so AWS-runner jobs are unaffected.
• use-fallback: true → falls back to the GitHub-hosted cache if RGW is briefly unreachable.
• Creds are inputs (passed from the org secrets HZ_CI_CACHE_S3_ACCESS_KEY/_SECRET_KEY), never baked.

Consumption (next, in the per-repo migration PRs)

hz jobs call e.g. milaboratory/github-ci/actions/golang/cache-s3@v4 with the org secrets; on rl8, rust/cache-s3 takes cargo-home: /opt/rust/cargo (the image bakes CARGO_HOME there).

Greptile Summary

Adds three additive cache-s3 composite actions (golang/cache-s3, rust/cache-s3, node/cache-pnpm-s3) that mirror their GitHub-cache siblings but route cache I/O through the Hetzner RadosGW via tespkg/actions-cache (pinned by full commit SHA). Existing actions and AWS-runner jobs are completely untouched.

• Each action preserves the exact same cache key scheme as its sibling so keys are portable and fallback to the GitHub-hosted cache (use-fallback: true) works seamlessly.
• rust/cache-s3 adds a cargo-home input (default ~/.cargo) to handle the hz-rl8 runner image where CARGO_HOME=/opt/rust/cargo is baked in.
• S3 credentials are injected as required inputs, never hardcoded; insecure defaults to false (TLS on).

Confidence Score: 4/5

All three actions are additive-only; no existing workflows are touched and the changes are straightforward YAML wrappers around a pinned third-party action.

The actions are well-structured mirrors of their siblings. Two observations temper a clean bill of health: retry-count is not a documented input of tespkg/actions-cache and is likely silently ignored, and golang/cache-s3 drops the save-always guarantee present in golang/cache so Go caches will not be written when a job fails mid-run.

All three files share the same retry-count concern; actions/golang/cache-s3/action.yaml additionally warrants a second look for the missing save-on-failure behaviour.

Important Files Changed

Filename	Overview
actions/golang/cache-s3/action.yaml	New S3-backed Go cache action for hz runners; mirrors sibling key scheme but omits save-always behavior and passes an unverified retry-count input.
actions/rust/cache-s3/action.yaml	New S3-backed Rust cache action with configurable cargo-home (needed for hz-rl8 image); same retry-count concern as golang sibling; otherwise clean.
actions/node/cache-pnpm-s3/action.yaml	New S3-backed pnpm cache action; dynamic store path resolved via pnpm store path, dual-path safety net carried from sibling; same retry-count concern.

Sequence Diagram

%%{init: {'theme': 'neutral'}}%%
sequenceDiagram
    participant Job as hz Runner Job
    participant Action as cache-s3 Action
    participant RGW as Hetzner RadosGW
    participant GHCache as GitHub-hosted Cache

    Job->>Action: invoke with access-key / secret-key
    Action->>RGW: restore cache (key lookup)
    alt RGW reachable
        RGW-->>Action: cache hit / miss
    else RGW unreachable and use-fallback true
        Action->>GHCache: restore cache (same key)
        GHCache-->>Action: cache hit / miss
    end
    Action-->>Job: cache restored (or cold build)
    Note over Job: build / test steps run
    alt Job succeeds
        Job->>Action: post-step: save cache
        Action->>RGW: upload cache artifact
        RGW-->>Action: saved
    else Job fails
        Note over Action: cache NOT saved to RGW
    end

Loading

%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
sequenceDiagram
    participant Job as hz Runner Job
    participant Action as cache-s3 Action
    participant RGW as Hetzner RadosGW
    participant GHCache as GitHub-hosted Cache

    Job->>Action: invoke with access-key / secret-key
    Action->>RGW: restore cache (key lookup)
    alt RGW reachable
        RGW-->>Action: cache hit / miss
    else RGW unreachable and use-fallback true
        Action->>GHCache: restore cache (same key)
        GHCache-->>Action: cache hit / miss
    end
    Action-->>Job: cache restored (or cold build)
    Note over Job: build / test steps run
    alt Job succeeds
        Job->>Action: post-step: save cache
        Action->>RGW: upload cache artifact
        RGW-->>Action: saved
    else Job fails
        Note over Action: cache NOT saved to RGW
    end

Loading

Prompt To Fix All With AI

Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
actions/golang/cache-s3/action.yaml:56-57
**`retry-count` may be silently ignored**

`retry` is a documented input for `tespkg/actions-cache`, but `retry-count` does not appear in the published action interface. GitHub Actions silently discards unrecognised `with:` keys, so all three actions would retry with the action's default count (likely 1–3) rather than the intended value of `3`. If you want a deterministic retry count, verify this input is supported at the pinned commit; otherwise remove it to avoid misleading configuration. The same pattern appears in `rust/cache-s3` and `node/cache-pnpm-s3`.

### Issue 2 of 2
actions/golang/cache-s3/action.yaml:60-76
**No `save-always` equivalent; cache not saved on job failure**

The sibling `golang/cache` defaults `cache-save-always: true`, which passes `save-always: true` to `actions/cache` so the cache is written even when a later step fails. `tespkg/actions-cache` does not document a `save-always` input, so the S3 action only saves on clean-run success. On the hz fleet, where jobs are more likely to see flaky infra failures, this means a partially-built Go module cache is silently discarded and the next run has to start cold. Consider documenting this divergence in the action description, or adding a separate post-step / `save-always`-like mechanism if the action supports it.

_{Reviews (1): Last reviewed commit: "feat: S3-backed cache-s3 siblings for go..." | Re-trigger Greptile}

Greptile also left 2 inline comments on this PR.

[greptile-apps]

retry-count may be silently ignored

retry is a documented input for tespkg/actions-cache, but retry-count does not appear in the published action interface. GitHub Actions silently discards unrecognised with: keys, so all three actions would retry with the action's default count (likely 1–3) rather than the intended value of 3. If you want a deterministic retry count, verify this input is supported at the pinned commit; otherwise remove it to avoid misleading configuration. The same pattern appears in rust/cache-s3 and node/cache-pnpm-s3.

Prompt To Fix With AI

This is a comment left during a code review.
Path: actions/golang/cache-s3/action.yaml
Line: 56-57

Comment:
**`retry-count` may be silently ignored**

`retry` is a documented input for `tespkg/actions-cache`, but `retry-count` does not appear in the published action interface. GitHub Actions silently discards unrecognised `with:` keys, so all three actions would retry with the action's default count (likely 1–3) rather than the intended value of `3`. If you want a deterministic retry count, verify this input is supported at the pinned commit; otherwise remove it to avoid misleading configuration. The same pattern appears in `rust/cache-s3` and `node/cache-pnpm-s3`.

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

No save-always equivalent; cache not saved on job failure

The sibling golang/cache defaults cache-save-always: true, which passes save-always: true to actions/cache so the cache is written even when a later step fails. tespkg/actions-cache does not document a save-always input, so the S3 action only saves on clean-run success. On the hz fleet, where jobs are more likely to see flaky infra failures, this means a partially-built Go module cache is silently discarded and the next run has to start cold. Consider documenting this divergence in the action description, or adding a separate post-step / save-always-like mechanism if the action supports it.

Prompt To Fix With AI

This is a comment left during a code review.
Path: actions/golang/cache-s3/action.yaml
Line: 60-76

Comment:
**No `save-always` equivalent; cache not saved on job failure**

The sibling `golang/cache` defaults `cache-save-always: true`, which passes `save-always: true` to `actions/cache` so the cache is written even when a later step fails. `tespkg/actions-cache` does not document a `save-always` input, so the S3 action only saves on clean-run success. On the hz fleet, where jobs are more likely to see flaky infra failures, this means a partially-built Go module cache is silently discarded and the next run has to start cold. Consider documenting this divergence in the action description, or adding a separate post-step / `save-always`-like mechanism if the action supports it.

How can I resolve this? If you propose a fix, please make it concise.