Tags: SonarSource/gh-action_cache
Tags
BUILD-10781 Migrate sub-actions to Node 24 and bump pinned actions to… … v5 (#75) GitHub deprecates Node 20 on Actions runners starting 2026-06-02 (full removal by Fall 2026). GitHub Actions metadata does not support `using: node22`; only node12/16/20/24 are valid, so the migration target is node24. Changes: - credential-setup, credential-guard, cache-metrics, symlink-keeper: `using: node20` -> `using: node24`. - action.yml: actions/cache v4.3.0 -> v5.0.5 (3 refs), runs-on/cache v4.3.0 -> v5.0.7. - Test workflows: actions/checkout -> v6.0.2, jdx/mise-action -> v4.0.1, actions/cache/save -> v5.0.5. - CLAUDE.md: update pinned-environment note to reflect Node 24 across all four sub-actions. ncc bundles regenerated locally; output is byte-identical because the TypeScript source is unchanged. Supersedes #58 (Renovate major GitHub actions bump).
BUILD-11295 Gate cache-metrics on layered decision file (workflow env… … > pre-job file) Replaces the simple `env.CI_METRICS_ENABLED == 'true'` gate on the `cache-metrics-prep` step with a layered check that honours both the workflow-level env override AND a presence-only decision file `${CI_METRICS_DIR}/enabled` written by the runner pre-job hook (github-runners-infra `hooks/job-started.sh`, sourcing the per-env, per-repo, per-workflow allow/deny resolver in `hooks/decide.sh`). New gate (one expression): runner.os == 'Linux' && env.CI_METRICS_ENABLED != 'false' && (env.CI_METRICS_ENABLED == 'true' || hashFiles(format('{0}/enabled', env.CI_METRICS_DIR)) != '') && steps.cache-backend.outputs.cache-backend == 's3' Semantics: - workflow `env.CI_METRICS_ENABLED == 'false'` → off (beats everything) - workflow `env.CI_METRICS_ENABLED == 'true'` → on (beats the allow/deny lists) - otherwise on iff the decision file exists at job-start New early step `Toggle CI metrics decision file` propagates the workflow's override to the file (touch on 'true', `rm -f` on 'false') so the post-job `job-completed.sh` hook sees the same decision the cache action did. The step also defaults `CI_METRICS_DIR=/tmp/ci-metrics` into $GITHUB_ENV so the subsequent `hashFiles()` expression has a stable path even on runners that don't pre-set the variable. Tests: - new `test-cache-metrics-via-decision-file` — file-only path, no env override - new `test-cache-metrics-workflow-false-beats-file` — env=false beats pre-touched file - existing env=true tests unchanged (the new gate still honours `'true'`) README documents the gate resolution order and links the workflow-env override to the file mutation, including the 4-line fallback setup step for workflows that don't use this action but still want to opt in / out. Aligns with BUILD-11295 design comment 919695 (the github-runners-infra side landed under the same branch name). Resolve CI-metrics gate in bash (hashFiles doesn't accept absolute paths) CI surfaced a real bug in the previous gate: hashFiles(format('{0}/enabled', env.CI_METRICS_DIR)) returns empty for absolute paths outside $GITHUB_WORKSPACE (well-known GHA constraint — hashFiles only globs under the workspace root). The decision file lives at `/tmp/ci-metrics/enabled`, so `test-cache-metrics-via-decision-file` failed: env.CI_METRICS_ENABLED was unset, hashFiles returned empty → gate off, metrics didn't run. Fix: collapse the gate into a single bash step (`Resolve CI metrics gate`) that: - applies the layered resolution in shell (env > file presence) - mutates the file when workflow env is set (so the post-job hook agrees) - emits `decision=true|false` as a step output The `cache-metrics-prep` gate becomes: steps.ci-metrics-gate.outputs.decision == 'true' && steps.cache-backend.outputs.cache-backend == 's3' No semantic change vs. the design: same priority order (workflow-false > workflow-true > file-present > no-signal). The decision is just computed in a place that can actually read `/tmp/ci-metrics/enabled`. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
BUILD-11297 Fix container self-reference and pre-commit git-clean reg… …ressions Two regressions surfaced when the BUILD-11068 metrics opt-in landed in sonar-dummy: 1. The cache-metrics local sub-action (`uses: ./.actions/cache-metrics`) failed to resolve in container jobs, even when the symlink target was reachable — observed in SonarSource/sonar-dummy/actions/runs/26102810763 (Integration Build / container). 2. The `git add -f .actions` workaround for `git clean -ffdx` was wiped by the follow-on `git reset --hard HEAD` + `git checkout --force <ref>` that actions/checkout runs after the clean, breaking the cache-metrics post step in any job that triggers a nested actions/checkout — observed in SonarSource/sonar-dummy/actions/runs/26102811096/job/76758257880 (pre-commit). ## Changes * action.yml * Merge the `Determine GitHub cache import mode` step into `Determine cache backend`. Both produce outputs read downstream; wrap each block under `::group::` to collapse the step-header noise from the runner log. * cache-metrics-prep applies the symlink-into-the-workspace pattern documented in SonarSource/ci-github-actions CONTRIBUTE.md (BUILD-9094): read `${{ github.action_path }}` inside the step, run `ls -la .actions/*`, `::group::`-wrap the body. This fix is what works in container jobs. * Restrict the metrics flow to the S3 backend. credential-guard (and its symlink keeper, below) only runs on S3; gating the prep step keeps the failure mode out of github-backend pipelines. * Pass `cache-metrics-action-path: ${{ github.action_path }}/cache-metrics` to credential-guard so its post step can recreate the workspace symlink. * credential-guard * New optional `cache-metrics-action-path` input. credential-guard-main persists it via core.saveState. * credential-guard-post calls a new `ensureCacheMetricsSymlink` helper before the existing AWS credential restore. The keeper recreates `.actions/cache-metrics` -> `<github.action_path>/cache-metrics` when the workspace symlink is gone — fail-open, never blocks the AWS work. Runs BEFORE cache-metrics' post step (LIFO order), so the runner can resolve `./.actions/cache-metrics/action.yml` when it reaches cache-metrics-post. * `post-if` bumped from `success()` to `always()`: cache-metrics-post uses `post-if: always()`, so its action.yml must be resolvable on the failure path too — otherwise the runner emits a hard "Can't find action.yml" error at job end. * Tests * New regression: `test-s3-cache-survives-git-clean-with-metrics` reproduces the pre-commit scenario by re-running actions/checkout after the cache step with `CI_METRICS_ENABLED='true'`. * credential-guard-main now has coverage for `cache-metrics-action-path` save/skip paths. * credential-guard-post.ensureCacheMetricsSymlink covered for no-op, existing valid link, recreation, and unreachable-target paths. * Empty-state path on credential-guard-post demoted from warning to info — it's the expected no-op shape when this invocation has no symlink-keeper or credential-restore work. Verified end-to-end on sonar-dummy `feat/jcarsique/BUILD-11294-test-cache-metrics`: * Integration-test (container): green. * Pre-commit (nested actions/checkout): green — keeper log shows `cache-metrics symlink keeper: recreated .actions/cache-metrics -> ...` followed by `cache-metrics: saved size = 407173108 B, saved=false, updated ...`.
PREQ-5729: fix argument list too long in cache cleanup (#61) * PREQ-5729: fix argument list too long in cache cleanup Pass delete JSON via file:// instead of inline argument to avoid exceeding ARG_MAX on repos with large caches (e.g. 1 TB+). * PREQ-5729: use trap for DELETE_FILE cleanup Extend the EXIT trap to cover DELETE_FILE so it gets cleaned up even if jq or another command fails mid-loop under set -e. Reset DELETE_FILE after each successful rm to avoid stale paths.
BUILD-10724: Import GitHub cache to S3 when no S3 cache exists (migra… …tion mode) When the S3 backend is used and the S3 cache misses, automatically attempt to restore the cache from GitHub using the original unprefixed key. The S3 post-job step will then save the restored content to S3, pre-provisioning it for subsequent runs. The feature is enabled by default. Resolution order to disable it: 1. Action input `import-github-cache: 'false'` 2. Environment variable `CACHE_IMPORT_GITHUB=false` 3. Default: true `fail-on-cache-miss` and `lookup-only` are propagated to the GitHub fallback step. When `fail-on-cache-miss` is set and import mode is active, failure is deferred until both S3 and GitHub have been tried. Also adds `.github/workflows/check-cache-migration.yml`: a manually-triggered workflow that compares GitHub cache entries to S3 objects across target branches (main, master, branch-*, dogfood-on-*, feature/long/*), ignoring transient keys (build-number-*, mise-*). When 100% of entries are found in S3, it automatically sets the CACHE_IMPORT_GITHUB=false repository variable to disable the import fallback (this requires the `CACHE_IMPORT_GITHUB` environment variable to be set from the repository variable via `${{ vars.CACHE_IMPORT_GITHUB }}`). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
PreviousNext