Parallel workflows containing jobs with the same name use the same cache key, resulting in "Failed to save cache entry" #699

lilgallon · 2023-05-03T10:02:27Z

Context

Here are the steps of our Github CI

            -   name: Build platform commons with Gradle
                uses: gradle/[email protected]
                env:
                    GRADLE_BUILD_ACTION_CACHE_DEBUG_ENABLED: true
                with:
                    gradle-version: 7.6
                    build-root-directory: systems/commons
                    arguments: build --parallel --scan -Pci -PlintIgnored -x test -x loadKtlintReporters  "-Dorg.gradle.jvmargs=-Xmx2G -XX:MaxMetaspaceSize=1G"
                    cache-read-only: ${{ github.ref != 'refs/heads/develop' }}

            -   name: Build platform base with Gradle
                uses: gradle/[email protected]
                env:
                    GRADLE_BUILD_ACTION_CACHE_DEBUG_ENABLED: true
                with:
                    gradle-version: 7.6
                    build-root-directory: systems/base
                    arguments: build --parallel --scan -Pci -PlintIgnored -x test -x loadKtlintReporters "-Dorg.gradle.jvmargs=-Xmx2G -XX:MaxMetaspaceSize=1G"
                    cache-read-only: ${{ github.ref != 'refs/heads/main' && github.ref != 'refs/heads/develop' }}

            -   name: Build platform tools with Gradle
                uses: gradle/[email protected]
                env:
                    GRADLE_BUILD_ACTION_CACHE_DEBUG_ENABLED: true
                with:
                    gradle-version: 7.6
                    build-root-directory: systems/platform
                    arguments: build --parallel --scan -Pci -PlintIgnored -x test -x distTar -x distZip -x loadKtlintReporters "-Dorg.gradle.jvmargs=-Xmx2G -XX:MaxMetaspaceSize=1G"
                    cache-read-only: ${{ github.ref != 'refs/heads/develop' }}

            -   name: Build platform with Gradle
                uses: gradle/[email protected]
                env:
                    GRADLE_BUILD_ACTION_CACHE_DEBUG_ENABLED: true
                with:
                    gradle-version: 7.6
                    arguments: build --parallel --scan -Pci -PlintIgnored -x test -x distTar -x distZip -x loadKtlintReporters "-Dorg.gradle.jvmargs=-Xmx2G -XX:MaxMetaspaceSize=1G"
                    cache-read-only: ${{ github.ref != 'refs/heads/develop' }}

            -   name: Run platform fastest tests with gradle
                uses: gradle/[email protected]
                env:
                    GRADLE_BUILD_ACTION_CACHE_DEBUG_ENABLED: true
                with:
                    gradle-version: 7.6
                    arguments: test --no-parallel --scan -Pfast -Pci -PlintIgnored "-Dorg.gradle.jvmargs=-Xmx2G -XX:MaxMetaspaceSize=1G"
                    cache-read-only: ${{ github.ref != 'refs/heads/develop' }}

            -   name: Run platform infrastructure tests with Gradle
                uses: gradle/[email protected]
                env:
                    GRADLE_BUILD_ACTION_CACHE_DEBUG_ENABLED: true
                with:
                    gradle-version: 7.6
                    arguments: test --no-parallel --scan -Plong -Pci -PlintIgnored "-Dorg.gradle.jvmargs=-Xmx2G -XX:MaxMetaspaceSize=1G"
                    cache-read-only: ${{ github.ref != 'refs/heads/develop' }}

From the logs of "Post build platform commons with Gradle":

  Caching Gradle User Home with cache key: v7-gradle|Linux|build[37a6259cc0c1dae299a7866489dff0bd]-0b6a99e5b69f94372a2cba9093df7c6801d274f2
  Using cache paths: /home/runner/.gradle/caches,/home/runner/.gradle/notifications,/home/runner/.gradle/.gradle-build-action
  /usr/bin/tar --posix -cf cache.tzst --exclude cache.tzst -P -C /home/runner/work/anoymous/anoymous --files-from manifest.txt --use-compress-program zstdmt
  Failed to save cache entry with path '/home/runner/.gradle/caches,/home/runner/.gradle/notifications,/home/runner/.gradle/.gradle-build-action,zstd-without-long,1.0' and key: v7-gradle|Linux|build[37a6259cc0c1dae299a7866489dff0bd]-0b6a99e5b69f94372a2cba9093df7c6801d274f2: ReserveCacheError: Unable to reserve cache with key v7-gradle|Linux|build[37a6259cc0c1dae299a7866489dff0bd]-0b6a99e5b69f94372a2cba9093df7c6801d274f2, another job may be creating this cache. More details: Cache already exists. Scope: refs/heads/develop, Key: v7-gradle|Linux|build[37a6259cc0c1dae299a7866489dff0bd]-0b6a99e5b69f94372a2cba9093df7c6801d274f2, Version: eb03f63337b25bd615bd5f2e3e2f06a28f197125b72943445f4e43a1c0565302

We had the problem using the version 2.2.2 of this action. Updating to 2.4.2 did not fix the issue.

Source of the problem

After investigating for a few hours, it turns out that a cache entry is systematically created between the "Build platform with Gradle" step and the "Run platform fastest tests with gradle" step. This cache entry is almost empty (usually around 8MB).

There is no log whatsoever indicating that the cache entry has been saved at this time.

Workaround:

I added a step that manually deletes the cache entry created during the build. Now there is no more problem when saving gradle home. The whole CI now takes between 5-10 minutes whereas it took more than 45 minutes before this workaround.

Notes:

This project is private, so I can not share it. I tried to reproduce it with an example project, the problem happened during the first action run (a cache entry for gradle home was saved during the build, its size was around 100kb). The next ones did not have the issue. I tried looking at the source code of this project, but I could not find the issue either.

I may try to find the issue later on and if I find it, I open a PR.

The text was updated successfully, but these errors were encountered:

bigdaz · 2023-05-03T16:51:30Z

Thanks for the report. The cache entry should only be written in the post-action of the step, which in this case would be "Post build platform commons with Gradle".
How did you deduce that the cache entry is being created during a different step in this workflow? It's very odd that there's no mention of the cache entry being created in the debug logs, and I don't understand how this would happen.

This error message usually results from a cache entry written during a previous execution of the workflow (with the same commit id). For example, if you use "Rerun Jobs" in the UI, or kickoff the workflow manually.

The fact that the cache entry is "almost empty" is not an indication of a problem. Most of the content of Gradle User Home is extracted into separate cache entries and is not contained in the main Gradle User Home cache entry.

I understand that the repository is private: are you able to share the logs (possibly redacted) or the Caching Summary with me directly? That might assist me to diagnose the problem.

lilgallon · 2023-05-04T09:25:46Z

Thanks for your answer :)

How did you deduce that the cache entry is being created during a different step in this workflow? It's very odd that there's no mention of the cache entry being created in the debug logs, and I don't understand how this would happen.

I don't understand either, so I made a video explaining how I found the issue. To sum up, while the workflow runs, I refresh the Github caches page, and during the build, we can see that a cache entry is saved. This cache entry contains the same thing as the cache entry that was restored initially.

gradle-build-cache-bug-report.webm

Note that instrumented-jars-sha also got saved prior to the post-action step whereas it should not
Typo: "when checking the logs, nothing says that gradle build action will some cache" -> "when checking the logs, nothing says that gradle-build-action will save some cache"

I can confirm you that there is no mention of the cache entry being created. I looked at the logs prior to the moment when the cache entry got saved. The only logs about cache are in the first step, when the cache is restored.

Logs:

  Requesting Gradle User Home with
      key:v7-gradle|Linux|build[37a6259cc0c1dae299a7866489dff0bd]-d4e6fc3e0323b40a3e5916d8c56fefdd5fadbb20
      restoreKeys:[v7-gradle|Linux|build[37a6259cc0c1dae299a7866489dff0bd],v7-gradle|Linux|build,v7-gradle|Linux]
  Using cache paths: /home/runner/.gradle/caches,/home/runner/.gradle/notifications,/home/runner/.gradle/.gradle-build-action
  Received 96468992 of 697324236 (13.8%), 92.0 MBs/sec
  Received 247463936 of 697324236 (35.5%), 117.9 MBs/sec
  Received 398458880 of 697324236 (57.1%), 126.5 MBs/sec
  Received 469762048 of 697324236 (67.4%), 111.9 MBs/sec
  Received 587202560 of 697324236 (84.2%), 111.9 MBs/sec
  Received 693129932 of 697324236 (99.4%), 110.1 MBs/sec
  Received 697324236 of 697324236 (100.0%), 109.6 MBs/sec
  Cache Size: ~665 MB (697324236 B)
  /usr/bin/tar -xf /home/runner/work/_temp/02a9dfd0-b642-4039-a24f-1160216eeec8/cache.tzst -P -C /home/runner/work/anonymous/anonymous --use-compress-program unzstd
  Cache restored successfully
  Restored Gradle User Home from cache key: v7-gradle|Linux|build[37a6259cc0c1dae299a7866489dff0bd]-8cc25137688dea90a1d1493435171469e0d05a9e
  Gradle User Home (directories >5M): as restored from cache
    6.3M    ./caches/modules-2/files-2.1
    15M    ./caches/modules-2/metadata-2.99/descriptors
    16M    ./caches/modules-2/metadata-2.99
    22M    ./caches/modules-2
    54M    ./caches/7.6/javaCompile
    13M    ./caches/7.6/executionHistory
    71M    ./caches/7.6
    650M    ./caches/build-cache-1
    179M    ./caches/transforms-3
    921M    ./caches
    921M    .
    921M    total
  -----------------------
  Loaded cache metadata: ***"entries":[***"artifactType":"generated-gradle-jars","pattern":"/home/runner/.gradle/caches/7.6/generated-gradle-jars/gradle-api-7.6.jar","cacheKey":"generated-gradle-jars-6c928a53124409c593074917d73bef59"***,***"artifactType":"kotlin-dsl","pattern":"/home/runner/.gradle/caches/*/kotlin-dsl/*/*","cacheKey":"kotlin-dsl-c95e53610734a7b7a46628097e4af6b6"***]***
  Received 1312169 of 1312169 (100.0%), 8.8 MBs/sec
  Cache Size: ~1 MB (1312169 B)
  /usr/bin/tar -xf /home/runner/work/_temp/28b2d5f3-d9f3-4bf3-a05e-568e5406d79c/cache.tzst -P -C /home/runner/work/anonymous/anonymous --use-compress-program unzstd
  Received 34941768 of 34941768 (100.0%), 61.3 MBs/sec
  Cache Size: ~33 MB (34941768 B)
  /usr/bin/tar -xf /home/runner/work/_temp/74c5223d-8178-4059-88e3-511152b555f0/cache.tzst -P -C /home/runner/work/anonymous/anonymous --use-compress-program unzstd
  Cache restored successfully
  Restored kotlin-dsl with key kotlin-dsl-c95e53610734a7b7a46628097e4af6b6 to /home/runner/.gradle/caches/*/kotlin-dsl/*/*
  Cache restored successfully
  Restored generated-gradle-jars with key generated-gradle-jars-6c928a53124409c593074917d73bef59 to /home/runner/.gradle/caches/7.6/generated-gradle-jars/gradle-api-7.6.jar
  Saving cache metadata: ***"entries":[***"artifactType":"generated-gradle-jars","pattern":"/home/runner/.gradle/caches/7.6/generated-gradle-jars/gradle-api-7.6.jar","cacheKey":"generated-gradle-jars-6c928a53124409c593074917d73bef59"***,***"artifactType":"kotlin-dsl","pattern":"/home/runner/.gradle/caches/*/kotlin-dsl/*/*","cacheKey":"kotlin-dsl-c95e53610734a7b7a46628097e4af6b6"***]***
  Gradle User Home (directories >5M): after restoring common artifacts
    6.3M    ./caches/modules-2/files-2.1
    15M    ./caches/modules-2/metadata-2.99/descriptors
    16M    ./caches/modules-2/metadata-2.99
    22M    ./caches/modules-2
    54M    ./caches/7.6/javaCompile
    16M    ./caches/7.6/kotlin-dsl/scripts
    57M    ./caches/7.6/kotlin-dsl/accessors
    74M    ./caches/7.6/kotlin-dsl
    150M    ./caches/7.6/generated-gradle-jars
    13M    ./caches/7.6/executionHistory
    291M    ./caches/7.6
    650M    ./caches/build-cache-1
    179M    ./caches/transforms-3
    1.2G    ./caches
    1.2G    .
    1.2G    total

Gradle build action settings (each step have the same settings, the only thing that changes, is the build-root-directory and arguments, as you can see in the original post):

gradle/gradle-build-action@v2
  with:
    gradle-version: 7.6
    build-root-directory: systems/commons
    arguments: build --parallel --scan -Pci -PlintIgnored -x test -x loadKtlintReporters  "-Dorg.gradle.jvmargs=-Xmx2G -XX:MaxMetaspaceSize=1G"
    cache-read-only: false
    cache-disabled: false
    cache-write-only: false
    gradle-home-cache-includes: caches
  notifications
  
    generate-job-summary: true
    gradle-home-cache-strict-match: false
    workflow-job-context: null
    gradle-home-cache-cleanup: false
  env:
    CLOUDSDK_AUTH_CREDENTIAL_FILE_OVERRIDE: anonymous
    GOOGLE_APPLICATION_CREDENTIALS: anonymous
    GOOGLE_GHA_CREDS_PATH: anonymous
    CLOUDSDK_CORE_PROJECT: anonymous
    CLOUDSDK_PROJECT: anonymous
    GCLOUD_PROJECT: anonymous
    GCP_PROJECT: anonymous
    GOOGLE_CLOUD_PROJECT: anonymous
    CLOUDSDK_METRICS_ENVIRONMENT: anonymous
    JAVA_HOME: /opt/hostedtoolcache/Java_Temurin-Hotspot_jdk/17.0.6-10/x64
    JAVA_HOME_17_X64: /opt/hostedtoolcache/Java_Temurin-Hotspot_jdk/17.0.6-10/x64
    GRADLE_BUILD_ACTION_CACHE_DEBUG_ENABLED: true

Cache summary (these logs are not the one of the video because we now have the workaround in the main branch, so we do not have the issue anymore. These logs are the ones of a run that happened before the workaround)

                 | Count | Total Size (Mb)
--               | --    | --
Entries Restored | 6     | 374
Entries Saved    | 3     | 587

Entry: Gradle User Home
    Requested Key : v7-gradle|Linux|build[37a6259cc0c1dae299a7866489dff0bd]-0b6a99e5b69f94372a2cba9093df7c6801d274f2
    Restored  Key : v7-gradle|Linux|build[37a6259cc0c1dae299a7866489dff0bd]-b36aa8b79637777aec60f00dd7cb6dba188a2a6f
              Size: 5 MB (4729366 B)
              (Entry restored: partial match found)
    Saved     Key : v7-gradle|Linux|build[37a6259cc0c1dae299a7866489dff0bd]-0b6a99e5b69f94372a2cba9093df7c6801d274f2
              Size: 
              (Entry not saved: entry with key already exists)
---
Entry: /home/runner/.gradle/caches/7.6/generated-gradle-jars/gradle-api-7.6.jar
    Requested Key : generated-gradle-jars-6c928a53124409c593074917d73bef59
    Restored  Key : generated-gradle-jars-6c928a53124409c593074917d73bef59
              Size: 33 MB (34941768 B)
              (Entry restored: exact match found)
    Saved     Key : 
              Size: 
              (Entry not saved: contents unchanged)
---
Entry: /home/runner/.gradle/caches/7.6/generated-gradle-jars/gradle-kotlin-dsl-extensions-7.6.jar
    Requested Key : generated-gradle-jars-c92a389859e7cb51961994838a98b964
    Restored  Key : generated-gradle-jars-c92a389859e7cb51961994838a98b964
              Size: 0 MB (124237 B)
              (Entry restored: exact match found)
    Saved     Key : 
              Size: 
              (Entry not saved: contents unchanged)
---
Entry: /home/runner/.gradle/caches/modules-*/files-*/*/*/*/*
    Requested Key : dependencies-c81117bcb9f974228aff395c73dcca6b
    Restored  Key : dependencies-c81117bcb9f974228aff395c73dcca6b
              Size: 193 MB (202892248 B)
              (Entry restored: exact match found)
    Saved     Key : dependencies-f818c4e1e3ca0fb8fe0186970c1479b8
              Size: 442 MB (463837913 B)
              (Entry saved)
---
Entry: /home/runner/.gradle/caches/jars-*/*
    Requested Key : instrumented-jars-ff2c89743514478a83933ec88bea1b14
    Restored  Key : instrumented-jars-ff2c89743514478a83933ec88bea1b14
              Size: 141 MB (148221756 B)
              (Entry restored: exact match found)
    Saved     Key : instrumented-jars-c350eaa8878cfe9c88ef59803bc8ab77
              Size: 142 MB (148525459 B)
              (Entry saved)
---
Entry: /home/runner/.gradle/caches/*/kotlin-dsl/*/*
    Requested Key : kotlin-dsl-eb74254e01f6bb8ebc482304198cccb8
    Restored  Key : kotlin-dsl-eb74254e01f6bb8ebc482304198cccb8
              Size: 1 MB (1526148 B)
              (Entry restored: exact match found)
    Saved     Key : kotlin-dsl-cd750dea519ceb95933a9f5b365a190a
              Size: 3 MB (2760790 B)
              (Entry saved)

Logs in the post-action step - only for gradle user home (these logs are not the one of the video because we now have the workaround in the main branch, so we do not have the issue anymore. These logs are the ones of a run that happened before the workaround):

Caching Gradle User Home with cache key: v7-gradle|Linux|build[37a6259cc0c1dae299a7866489dff0bd]-0b6a99e5b69f94372a2cba9093df7c6801d274f2
  Using cache paths: /home/runner/.gradle/caches,/home/runner/.gradle/notifications,/home/runner/.gradle/.gradle-build-action
  /usr/bin/tar --posix -cf cache.tzst --exclude cache.tzst -P -C /home/runner/work/anonymous/anonymous --files-from manifest.txt --use-compress-program zstdmt
  Failed to save cache entry with path '/home/runner/.gradle/caches,/home/runner/.gradle/notifications,/home/runner/.gradle/.gradle-build-action,zstd-without-long,1.0' and key: v7-gradle|Linux|build[37a6259cc0c1dae299a7866489dff0bd]-0b6a99e5b69f94372a2cba9093df7c6801d274f2: ReserveCacheError: Unable to reserve cache with key v7-gradle|Linux|build[37a6259cc0c1dae299a7866489dff0bd]-0b6a99e5b69f94372a2cba9093df7c6801d274f2, another job may be creating this cache. More details: Cache already exists. Scope: refs/heads/develop, Key: v7-gradle|Linux|build[37a6259cc0c1dae299a7866489dff0bd]-0b6a99e5b69f94372a2cba9093df7c6801d274f2, Version: eb03f63337b25bd615bd5f2e3e2f06a28f197125b72943445f4e43a1c0565302

This error message usually results from a cache entry written during a previous execution of the workflow (with the same commit id). For example, if you use "Rerun Jobs" in the UI, or kickoff the workflow manually.

I can confirm to you that the issue happen without triggering a job rerun, as you can see in the video.

The fact that the cache entry is "almost empty" is not an indication of a problem. Most of the content of Gradle User Home is extracted into separate cache entries and is not contained in the main Gradle User Home cache entry.

Yes, indeed, I realized that the cache entry that gets saved before the post-action step is actually the same as the one initially restored. My bad, I was wrong on this part.

bigdaz · 2023-05-04T11:49:59Z

Thanks for all of the details! This is most perplexing.

Only the post-action contains the logic to save a cache entry. And my understanding/experience is that post-actions will be executed after all of the main actions have run.

There is also lots of logging around saving a cache entry. It doesn't seem possible that the action saves a cache entry without any evidence in the logs.

I can think of only 2 explanations based on the gradle-build-action code (and the lack of log messages):

1. GitHub Actions is somehow executing the `post action` for first step prior to completion all of the other steps.

Can you please inspect the logs contained in the post-action steps (for the bad run) to find any "Caching Gradle User Home with cache key: X" log messages? You'll be able to see all logs (with timestamps) using "View raw logs".

2. There is a parallel Job executing that is writing the cache entry, and that workflow is generating the same cache key.

Can you confirm whether there were any other GitHub actions Jobs / workflows running in parallel?
If so, can you please inspect the logs to see if the same cache key is being used?

lilgallon · 2023-05-04T12:18:20Z

Thank you for your response!

I found the issue. I have 2 Jobs running in parallel (one for backend, one for frontend to give you some context), and both use gradle-build-action. In the logs, both generate the same cache key. The frontend job is faster than the backend job, so the frontend job saves the cache while the backend is still running.

I thought that it was not possible.

url for frontend: actions/runs/4880423500/jobs/8708061412
url for backend: actions/runs/4880423487/jobs/8708061336

According to the README:

The state of the Gradle User Home is highly dependent on the Gradle execution, so the cache key is composed of the current commit hash and the GitHub actions job id.

Shouldn't the cache keys be different in my case ? It's important to share cache between jobs, but the key should be different across different workflows

Message:

Caching Gradle User Home with cache key: v7-gradle|Linux|build[37a6259cc0c1dae299a7866489dff0bd]-d4e6fc3e0323b40a3e5916d8c56fefdd5fadbb20

bigdaz · 2023-05-04T14:27:46Z

Shouldn't the cache keys be different in my case ? It's important to share cache between jobs, but the key should be different across different workflows

Yes the keys should be different. Here's the logic that determines the cache key, and looking at it now I can see that 2 workflows that have jobs with the same name could produce the same cache key. This is unintentional.

Thanks for helping to track this down. A fix for this will be to include the workflow name/id when identifying the Job in the cache key.

In the meantime, you can override this by setting the GRADLE_BUILD_ACTION_CACHE_KEY_JOB environment variable for each Job (undocumented: see code here). If you make this different in the 2 different workflows then they will have separate cache keys.

Please let me know if that allows you to remove your current workaround. I'll be sure to get this fixed for the next release.

bigdaz · 2023-05-04T14:47:33Z

PS There are a couple of recommendations I'd make to simplify your build/workflows.

Add org.gradle.jvmargs=-Xmx2G -XX:MaxMetaspaceSize=1G" to gradle.properties and commit to the sources. This means that anyone building the project (locally or CI) will have the correct JVM settings.
Apply the Gradle Enterprise plugin and always publish build scans from CI. Then you can remove the --scan from the args.

// settings.gradle
plugins {
    id "com.gradle.enterprise" version "3.13.1"
}
gradleEnterprise {
    buildScan {
        publishAlwaysIf(System.getenv("CI"))
    }
}

Use the gradle-build-action to "Setup Gradle", but not for each Gradle invocation

    -  name: Setup Gradle
        uses: gradle/[email protected]
        env:
            GRADLE_BUILD_ACTION_CACHE_DEBUG_ENABLED: true
        with:
            gradle-version: 7.6 # This is not required if your build uses the Gradle wrapper
            cache-read-only: ${{ github.ref != 'refs/heads/develop' }}

    -   name: Build platform commons with Gradle
        working-directory: systems/commons
        run: ./gradlew build --parallel -Pci -PlintIgnored -x test -x loadKtlintReporters             

    -   name: Build platform base with Gradle
        working-directory: systems/base
        run: ./gradlew build --parallel -Pci -PlintIgnored -x test -x loadKtlintReporters             

    -   name: Build platform tools with Gradle
        working-directory: systems/base
        run: ./gradlew build --parallel -Pci -PlintIgnored -x test -x distTar -x distZip -x loadKtlintReporters

    -   name: Build platform with Gradle
         run: ./gradlew build --parallel -Pci -PlintIgnored -x test -x distTar -x distZip -x loadKtlintReporters 

    -   name: Run platform fastest tests with gradle
        run: ./gradlew test --no-parallel -Pfast -Pci -PlintIgnored

    -   name: Run platform infrastructure tests with Gradle
        run: ./gradlew test --no-parallel -Plong -Pci -PlintIgnored

lilgallon · 2023-05-04T15:09:28Z

I can confirm you that both workflows have the same job name: "build", that's why the key was:

v7-gradle|Linux|build[37a6259cc0c1dae299a7866489dff0bd]-d4e6fc3e0323b40a3e5916d8c56fefdd5fadbb20

I changed jobs' names, and now I have two different cache entries:

v7-gradle|Linux|build-backend[37a6259cc0c1dae299a7866489dff0bd]-d4e6fc3e0323b40a3e5916d8c56fefdd5fadbb20
v7-gradle|Linux|build-frontend[37a6259cc0c1dae299a7866489dff0bd]-d4e6fc3e0323b40a3e5916d8c56fefdd5fadbb20

Thank you for your suggestions, it is super valuable! I just made the modifications. The only thing is that I added org.gradle.jvmargs=-Xmx2G -XX:MaxMetaspaceSize=1G" because otherwise the Github VM crashes (that's also the reason of --no-parallel for tests). Locally, we want higher jvm settings than the ones in the CI. Using large Github runner may fix the issue though.

Thank you again for your reactivity, and your work :)

bigdaz · 2023-05-06T14:40:19Z

Glad to hear you got this sorted. We'll be sure to fix this in an upcoming release so that others don't hit this issue.

Fixes #699 by avoiding cache key collisions between jobs with the same name in different workflows.

pavel-spacil · 2023-06-29T06:09:44Z

I think we're experiencing an issue after this change. 🤔
We have a workflow which has a name with comma: Build, test and deploy and some jobs are using this action. That started to fail since today with an error:

ValidationError: Key Validation Error: v8-gradle|Linux|Build, test and deploy-build-and-test-code[37a6259cc0c1dae299a7866489dff0bd]-7e6e283daa6662e3fbcaffbf38abebc2169ab560 cannot contain commas.

Wouldn't it be better to use the worklow filename instead of name in the cache key?

Btw the override proposed here points to a different env var, is that intentional?

Thanks!

bigdaz · 2023-06-29T15:11:58Z

Wouldn't it be better to use the worklow filename instead of name in the cache key?

Yes I'll see if this is available via an GH env var. But I think it still will make sense to sanitize the cache key to remove commas and other illegal characters.

lilgallon changed the title ~~A cache entry is always created after the last build step, causing an error when saving gradle home in "Post build" operation~~ Parallel jobs use the same cache key, causing the longer job to fail when saving its cache because the cache entry already exists May 4, 2023

bigdaz changed the title ~~Parallel jobs use the same cache key, causing the longer job to fail when saving its cache because the cache entry already exists~~ Parallel workflows containing Jobs with the same name use the same cache key, resulting in "Failed to save cache entry" May 4, 2023

bigdaz changed the title ~~Parallel workflows containing Jobs with the same name use the same cache key, resulting in "Failed to save cache entry"~~ Parallel workflows containing jobs with the same name use the same cache key, resulting in "Failed to save cache entry" May 4, 2023

bigdaz added a commit that referenced this issue May 23, 2023

Include workflow name in cache key

c20f502

Fixes #699 by avoiding cache key collisions between jobs with the same name in different workflows.

bigdaz closed this as completed in 2bf6bc3 May 23, 2023

bigdaz added this to the 2.5.0 milestone Jun 28, 2023

bigdaz added the bug Something isn't working label Jun 28, 2023

vanshg mentioned this issue Jun 29, 2023

Workflows containing commas in their name fail #758

Closed

jumaallan mentioned this issue Jun 29, 2023

Debug Failing Workflow smileidentity/android#133

Merged

kslesinski-godaddy mentioned this issue Dec 28, 2023

Share cache entry between matching Jobs in different workflows #1017

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Parallel workflows containing jobs with the same name use the same cache key, resulting in "Failed to save cache entry" #699

Parallel workflows containing jobs with the same name use the same cache key, resulting in "Failed to save cache entry" #699

lilgallon commented May 3, 2023 •

edited

Loading

bigdaz commented May 3, 2023

lilgallon commented May 4, 2023 •

edited

Loading

bigdaz commented May 4, 2023 •

edited

Loading

lilgallon commented May 4, 2023 •

edited

Loading

bigdaz commented May 4, 2023

bigdaz commented May 4, 2023

lilgallon commented May 4, 2023

bigdaz commented May 6, 2023

pavel-spacil commented Jun 29, 2023

bigdaz commented Jun 29, 2023

Parallel workflows containing jobs with the same name use the same cache key, resulting in "Failed to save cache entry" #699

Parallel workflows containing jobs with the same name use the same cache key, resulting in "Failed to save cache entry" #699

Comments

lilgallon commented May 3, 2023 • edited Loading

bigdaz commented May 3, 2023

lilgallon commented May 4, 2023 • edited Loading

bigdaz commented May 4, 2023 • edited Loading

1. GitHub Actions is somehow executing the post action for first step prior to completion all of the other steps.

2. There is a parallel Job executing that is writing the cache entry, and that workflow is generating the same cache key.

lilgallon commented May 4, 2023 • edited Loading

bigdaz commented May 4, 2023

bigdaz commented May 4, 2023

lilgallon commented May 4, 2023

bigdaz commented May 6, 2023

pavel-spacil commented Jun 29, 2023

bigdaz commented Jun 29, 2023

lilgallon commented May 3, 2023 •

edited

Loading

lilgallon commented May 4, 2023 •

edited

Loading

bigdaz commented May 4, 2023 •

edited

Loading

1. GitHub Actions is somehow executing the `post action` for first step prior to completion all of the other steps.

lilgallon commented May 4, 2023 •

edited

Loading