PREQ-6373: Store build-number cache in S3 via runs-on/cache split

[matemoln]

Summary

• Replace actions/cache/restore + actions/cache/save in get-build-number with gh-action_cache/credential-setup and runs-on/cache/restore + runs-on/cache/save, storing build numbers in SonarSource S3 (sonarsource-s3-cache-prod-bucket)
• Use branch-prefixed cache keys ({github.head_ref || github.ref}/build-number-{run_id}) aligned with gh-action_cache S3 layout
• Keep the split restore → increment → save → cleanup lifecycle so .build_number.txt is removed from the workspace after save
• Re-enable exit 1 on cross-job reuse mismatches in Test Build Number (previously commented out as flaky under GitHub Actions cache)

Test plan

• Test Build Number workflow passes (generation, same-job stability, cross-job Linux reuse, cross-OS Windows reuse, env bypass)
• Confirm build number is not re-incremented on workflow rerun (S3 cache hit)
• Verify consuming workflows still work with id-token: write permission

[hashicorp-vault-sonar-prod]

PREQ-6373

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues
0 New dependency risks

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[gitar-bot]

💡 Quality: Duplicated AWS credential env across restore/save steps

The full AWS credential/config env block (RUNS_ON_S3_BUCKET_CACHE, AWS_DEFAULT_REGION, AWS_REGION, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, AWS_PROFILE, AWS_DEFAULT_PROFILE) is copy-pasted verbatim into both the Get cached build number (restore) step and the Save build number to cache step in get-build-number/action.yml. Any future change (bucket name, region) must be edited in two places, creating a drift risk where restore and save could end up pointing at different buckets/regions and silently miss the cache. Composite actions don't support job-level env, but you can reduce duplication by setting the static values once via $GITHUB_ENV in the existing Set local action paths step (e.g. RUNS_ON_S3_BUCKET_CACHE, AWS_*_REGION) and only repeating the per-step credential outputs, or by factoring the cache logic out. At minimum, keep the two blocks identical to avoid restore/save mismatches.

_{Was this helpful? React with 👍 / 👎}

[gitar-bot]

CI failed: The transition to S3-based caching for build numbers is causing cross-job state synchronization failures, leading to test regressions where sequential jobs fetch inconsistent build numbers.

Overview

The PR changes the build-number cache implementation to use S3, but this has caused consistent failures in cross-job cache synchronization. Across 3 analyzed logs, tests in both Windows and Linux environments are failing to retrieve the previously cached build number, resulting in build number mismatches (e.g., getting 3885 instead of 3884).

Failures

Build Number Cache Discrepancy (confidence: high)

• Type: test
• Affected jobs: test-build-number-reuse-from-cache, test-build-number-reuse-from-cache-windows
• Related to change: yes
• Root cause: The migration to S3-based caching is failing to correctly restore the state between jobs. The get-build-number logic is likely generating a new build number instead of successfully retrieving the existing one, or the S3 cache key/storage logic is not deterministic across the workflow execution.
• Suggested fix: Validate that the cache key generation is identical for all jobs within the same run. Debug the get-build-number action to confirm that the S3 retrieval logic correctly detects and restores the .build_number.txt file before the build number is accessed.

Summary

• Change-related failures: 3 occurrences of build number mismatch failures across Windows and Linux test jobs.
• Infrastructure/flaky failures: 0.
• Recommended action: Review the implementation of the S3 cache retrieval within get-build-number/action.yml. Ensure the S3 bucket lookup logic for .build_number.txt is consistent with previous actions/cache behavior and that the HIT_S3 output is correctly prioritized during the retrieval phase.

Code Review 👍 Approved with suggestions 0 resolved / 1 findings

Migration to S3-backed caching for build numbers improves cross-job reliability and re-enables strict failure checks. Consolidate duplicated AWS credential environment variables into a reusable template to reduce step configuration verbosity.

💡 Quality: Duplicated AWS credential env across restore/save steps

📄 get-build-number/action.yml:55-63 📄 get-build-number/action.yml:95-103

The full AWS credential/config env block (RUNS_ON_S3_BUCKET_CACHE, AWS_DEFAULT_REGION, AWS_REGION, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, AWS_PROFILE, AWS_DEFAULT_PROFILE) is copy-pasted verbatim into both the Get cached build number (restore) step and the Save build number to cache step in get-build-number/action.yml. Any future change (bucket name, region) must be edited in two places, creating a drift risk where restore and save could end up pointing at different buckets/regions and silently miss the cache. Composite actions don't support job-level env, but you can reduce duplication by setting the static values once via $GITHUB_ENV in the existing Set local action paths step (e.g. RUNS_ON_S3_BUCKET_CACHE, AWS_*_REGION) and only repeating the per-step credential outputs, or by factoring the cache logic out. At minimum, keep the two blocks identical to avoid restore/save mismatches.

🤖 Prompt for agents

Code Review: Migration to S3-backed caching for build numbers improves cross-job reliability and re-enables strict failure checks. Consolidate duplicated AWS credential environment variables into a reusable template to reduce step configuration verbosity.

1. 💡 Quality: Duplicated AWS credential env across restore/save steps
   Files: get-build-number/action.yml:55-63, get-build-number/action.yml:95-103

   The full AWS credential/config env block (RUNS_ON_S3_BUCKET_CACHE, AWS_DEFAULT_REGION, AWS_REGION, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, AWS_PROFILE, AWS_DEFAULT_PROFILE) is copy-pasted verbatim into both the `Get cached build number` (restore) step and the `Save build number to cache` step in get-build-number/action.yml. Any future change (bucket name, region) must be edited in two places, creating a drift risk where restore and save could end up pointing at different buckets/regions and silently miss the cache. Composite actions don't support job-level env, but you can reduce duplication by setting the static values once via `$GITHUB_ENV` in the existing `Set local action paths` step (e.g. RUNS_ON_S3_BUCKET_CACHE, AWS_*_REGION) and only repeating the per-step credential outputs, or by factoring the cache logic out. At minimum, keep the two blocks identical to avoid restore/save mismatches.

Tip

Comment Gitar fix CI or enable auto-apply: gitar auto-apply:on

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}