Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cache Incompatibility Between ARC and Non-ARC Runners in GitHub Actions #1440

Open
GeunSam2 opened this issue Jul 24, 2024 · 3 comments
Open

Comments

@GeunSam2
Copy link

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

  1. 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
  2. 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 enableCrossOsArchive set 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.

@sb185296
Copy link

sb185296 commented Sep 1, 2024

i have same problem !
what we can do to fix it ???

@vlad-oj
Copy link

vlad-oj commented Sep 4, 2024

I suppose it has the same nature as described here #1455 (comment)

OhmSpectator added a commit to OhmSpectator/eve that referenced this issue Sep 24, 2024
This reverts commit 55e539d.

The recent switch to GitHub-hosted runners introduced issues with
actions/cache path handling, resulting in build failures due to
inconsistent home directory depths. Reverting to self-hosted runners to
restore build stability and functionality.

References:
- Issue: actions/cache#1440

Signed-off-by: Nikolay Martyanov <nikolay@zededa.com>
@deitch
Copy link

deitch commented Sep 24, 2024

The problem, I believe, is here:

  const workspace = process.env['GITHUB_WORKSPACE'] ?? process.cwd()
  const globber = await glob.create(patterns.join('\n'), {
    implicitDescendants: false
  })

  for await (const file of globber.globGenerator()) {
    const relativeFile = path
      .relative(workspace, file)
      .replace(new RegExp(`\\${path.sep}`, 'g'), '/')
    core.debug(`Matched: ${relativeFile}`)

It uses path.relative() to resolve file relative to workspace, but that is not what path.relative does. The docs state:

The path.relative() method returns the relative path from from to to based on the current working directory. If from and to each resolve to the same path (after calling path.resolve() on each), a zero-length string is returned.

It is doing the relative path to something based on the current working directory. Here is a simple test.

$ mkdir /tmp/foo && cd /tmp/foo
$ node
> path.relative("/a/b/c", "../q")
'../../../tmp/q'

I think they were looking for ../q, i.e. "q as relative to /a/b/c, and not "how do I get to q relative to abc given my current working directory?"

I should open an issue there, or make a dedicated one here.

deitch pushed a commit to lf-edge/eve that referenced this issue Sep 25, 2024
This reverts commit 55e539d.

The recent switch to GitHub-hosted runners introduced issues with
actions/cache path handling, resulting in build failures due to
inconsistent home directory depths. Reverting to self-hosted runners to
restore build stability and functionality.

References:
- Issue: actions/cache#1440

Signed-off-by: Nikolay Martyanov <nikolay@zededa.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants