PREQ-6373: Fix regression with build-number cache path

[matemoln]

Summary

Fixes the regression introduced in #287 (BUILD-11553), where moving the build-number cache file to ${RUNNER_TEMP}/build_number.txt broke cache restore across jobs on different runner types and OSes.

• Store the build-number cache at .build_number.txt (workspace-relative) instead of ${RUNNER_TEMP}/build_number.txt, which differs between GitHub-hosted and ARC runners and breaks actions/cache restore across jobs
• actions/cache rejects .. in paths, so parent-directory locations cannot be cached; a workspace-relative file with enableCrossOsArchive: true works across Linux and Windows runners
• After exporting BUILD_NUMBER to GITHUB_ENV / outputs and saving the cache, remove the file from the workspace so calling workflows are not polluted (preserving the intent of BUILD-11553: Avoid workspace pollution in CI actions #287)
• Use .build_number.txt rather than build_number.txt to avoid colliding with a tracked file in consuming repositories; document the reserved filename in the README
• Simplify get_build_number.sh by using BUILD_NUMBER_FILE directly instead of a separate CACHE_FILE alias
• Add a workspace cleanliness check to test-build-number-generation (git status --porcelain must be empty after get-build-number); drop /build_number.txt from .gitignore so a leftover cache file is visible to git status

Note

• We can not make test-build-number-reuse-from-cache jobs fail the workflow when the build number does not match, due to the flakyness of GitHub hosted cache

Test plan

• shellspec spec/get_build_number_spec.sh passes locally
• CI Test Build Number workflow passes on the PR (cross-runner and cross-OS cache reuse, workspace not polluted)
• Verify cache restore works across jobs on different ARC runners in sonar-dotnet-a3s

[hashicorp-vault-sonar-prod]

PREQ-6373

[Copilot]

Pull request overview

This PR updates the build-number caching strategy for the get-build-number composite action by moving the cached build_number.txt from ${RUNNER_TEMP} to a path relative to the workspace, aiming to avoid cache misses across different runner types in the same workflow.

Changes:

• Switch the build-number cache file location to ../build_number.txt.
• Simplify get_build_number.sh by writing directly to BUILD_NUMBER_FILE (removing the CACHE_FILE alias).
• Update ShellSpec coverage to assert against BUILD_NUMBER_FILE directly.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
spec/get_build_number_spec.sh	Updates the test to use the new BUILD_NUMBER_FILE path and validate the written cache file.
get-build-number/get_build_number.sh	Changes the default build-number cache file location and writes the incremented build number to it.
get-build-number/action.yml	Exports the new cache file path via GITHUB_ENV so cache restore/save and subsequent steps use it.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[julien-carsique-sonarsource]

Initially, it was build_number.txt. Replacing with ../build_number.txt should work as well.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud

[gitar-bot]

Code Review ✅ Approved 3 resolved / 3 findings

Restores cross-runner cache persistence by relocating the build number file to the workspace root and cleaning it up post-execution. Ensure the unconditional workspace cleanup does not inadvertently delete pre-existing user files matching the .build_number.txt naming convention.

✅ 3 resolved

✅ Edge Case: rm -f may delete a user's existing build_number.txt

📄 get-build-number/action.yml:32 📄 get-build-number/action.yml:86-89
BUILD_NUMBER_FILE is now a workspace-relative path (build_number.txt). The action both writes to this path and unconditionally removes it via rm -f "$BUILD_NUMBER_FILE" with if: always(). The action's default working directory is GITHUB_WORKSPACE, which is the checked-out repository. If a consuming repository happens to track a file named build_number.txt at its root, this action will overwrite it and then delete it, causing silent data loss / a dirty working tree for the caller. Consider using a less collision-prone name (e.g. .build_number.txt or a dedicated subdir) or only removing the file if the action created it. At minimum, document the reserved filename.

✅ Quality: mktemp temp dir is never cleaned up in spec

📄 spec/get_build_number_spec.sh:5-6
The spec now creates a temp directory via TEMP_DIR=$(mktemp -d) and points BUILD_NUMBER_FILE at it, but nothing ever removes TEMP_DIR. The previous approach used ${SHELLSPEC_TMPBASE:-/tmp}, where SHELLSPEC_TMPBASE is managed and cleaned up by shellspec automatically. Each run of this spec now leaks a temp directory under the system temp location. Consider reusing the shellspec-managed temp base (e.g. TEMP_DIR="${SHELLSPEC_TMPBASE:-$(mktemp -d)}") or register a cleanup hook (AfterAll 'rm -rf "$TEMP_DIR"') so the directory is removed after the suite.

✅ Edge Case: Cleanup rm -f deletes a pre-existing workspace .build_number.txt

📄 get-build-number/action.yml:86-89
The new 'Remove build number file from workspace' step runs rm -f "$BUILD_NUMBER_FILE" with if: always(), where BUILD_NUMBER_FILE resolves to the workspace-relative .build_number.txt. If a consuming repository already has a file named .build_number.txt checked out (tracked or untracked), this step deletes it from the workspace whenever the action runs — including on the from-env path. This is now documented in the README as a reserved filename, which mitigates the risk, so severity is minor. If you want to be safer, only remove the file when the action itself created it (e.g. record a marker before writing) so a user's file is never silently removed.

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}