Cache Incompatibility Between ARC and Non-ARC Runners in GitHub Actions
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 5.6k
- Forks
- 1.6k
- PR merge metrics
- No merged PRs in 30d
Description
Description
There is a cache compatibility issue between ARC (Action Runner Controller) runners and non-ARC runners in GitHub Actions. Caches created by ARC runners cannot be restored by non-ARC runners, and vice versa. This issue limits the interoperability between different runner environments, causing inefficiencies in workflows that utilize both ARC and non-ARC runners.
Steps to Reproduce
-
Scenario 1: Non-ARC to ARC
-
First Job: Non-ARC Runner (e.g., Self-hosted, github hosted ...)
jobs: build: runs-on: self-hosted steps: - uses: actions/checkout@v4 - name: Generate Cache id: generate-cache run: | mkdir -p ./path/to/cache echo "This is a test cache" > ./path/to/cache/test.txt - name: Save Cache uses: actions/cache/save@v4 with: path: ./path/to/cache key: cache-${{ github.run_id }} enableCrossOsArchive: true -
Second Job: ARC Runner
jobs: test: needs: build runs-on: k8s-ubuntu-x64-4cores steps: - uses: actions/checkout@v4 - name: Restore Cache id: restore-cache uses: actions/cache/restore@v4 with: path: ./path/to/cache key: cache-${{ needs.build.outputs.cache-key }} restore-keys: cache- enableCrossOsArchive: true - name: Check Cache run: | if [ -f "./path/to/cache/test.txt" ]; then echo "Cache restored successfully" else echo "Cache not found" fi
-
-
Scenario 2: ARC to Non-ARC
-
First Job: ARC Runner
jobs: build: runs-on: k8s-ubuntu-x64-4cores steps: - uses: actions/checkout@v4 - name: Generate Cache id: generate-cache run: | mkdir -p ./path/to/cache echo "This is a test cache" > ./path/to/cache/test.txt - name: Save Cache uses: actions/cache/save@v4 with: path: ./path/to/cache key: cache-${{ github.run_id }} enableCrossOsArchive: true -
Second Job: Non-ARC Runner
jobs: test: needs: build runs-on: self-hosted steps: - uses: actions/checkout@v4 - name: Restore Cache id: restore-cache uses: actions/cache/restore@v4 with: path: ./path/to/cache key: cache-${{ needs.build.outputs.cache-key }} restore-keys: cache- enableCrossOsArchive: true - name: Check Cache run: | if [ -f "./path/to/cache/test.txt" ]; then echo "Cache restored successfully" else echo "Cache not found" fi
-
Expected Behavior
The cache should be successfully restored across different runner environments.
Actual Behavior
The cache fails to restore, displaying a "Cache not found" message, despite the cache being available and correctly generated.
Additional Information
- The cache is verified to exist and is accessible within the repository's cache storage.
- The issue occurs in both directions: ARC to non-ARC and non-ARC to ARC.
- Both environments have
enableCrossOsArchiveset to true to allow cross-OS cache compatibility.
Environment Details
- Non-ARC Runner: Self-hosted, running on a different operating system.
- ARC Runner: Kubernetes-based runner managed by ARC in a Kubernetes cluster.
- GitHub Actions Cache Version: v4
Impact
This issue limits the flexibility and interoperability of using different runner types within the same workflow, leading to inefficiencies and potential workflow redesign to avoid mixed runner environments.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the two workflows using actions/cache/save@v4 and actions/cache/restore@v4 with ARC and non-ARC runners, then compare cache keys and restore logs in both directions. Done means the generated cache is restored successfully across both runner environments with enableCrossOsArchive enabled.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions, kubernetes
- Domain
- ci-cd, infrastructure
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 35/100