satackey / action-docker-layer-caching

[CAUTION] This repository is not actively maintained. / Enable Docker layer caching in your GitHub Actions workflow.
https://github.com/marketplace/actions/docker-layer-caching
MIT License
421 stars 55 forks source link

Caching across runs #169

Open andre-lx opened 3 years ago

andre-lx commented 3 years ago

Describe the bug

Using the following configuration, the cache works great across jobs in the same run (even with the default values of key and restore-keys, but, re-running the workflow, the cache is never found:

  job1:
    name: job1
    runs-on: ubuntu-20.04

    steps:
    - uses: actions/checkout@v2

    - uses: satackey/action-docker-layer-caching@v0.0.11
      with:
        key: images-docker-cached-${{ github.workflow }}
        restore-keys: |
          images-docker-cached-

    - name: Build images
      run: |
        cd docker-compose/
        docker-compose -f docker-compose-images.yaml build

Output:

Root cache could not be found. aborting.

Don't know if it's related with: https://github.com/satackey/action-docker-layer-caching/issues/49

Because the post step works fine, and again, puts all the layers in cache (and can be used in the next job), but never in the next run.

Expected behavior The cache can be used across different runs.

Runner Environment:

I am doing something wrong?

Thanks

Bilge commented 3 years ago

So, basically the whole point of this action doesn't even work?


Edit: NVM works for me lol xD


Edit: Doesn't work for different build types, e.g. cache is not shared between push and PR, even if the PR is for a single commit that was already built.

cscetbon commented 3 years ago

I was also surprised to see this. In my case I have a run that is triggered by a regular push, then another one when I tag the version. I was expecting the second to not rebuild docker images but it does 🤷‍♂️. They are the same commit so I would expect the cache to work in that case. I'm using docker-compose to build my images.

Run of the push before tagging it

with:
  key: docker-layer-caching-SATTL-{hash}
  restore-keys: docker-layer-caching-SATTL-
  concurrency: 4
  skip-save: false
env:
  AWS_DEFAULT_REGION: us-west-2
  AWS_REGION: us-west-2
  AWS_ACCESS_KEY_ID: ***
  AWS_SECRET_ACCESS_KEY: ***
Received 10853 of 10853 (100.0%), 0.2 MBs/sec
...
Cache saved successfully
119
Stored layer cache: {"key":"layer-docker-layer-caching-SATTL-f0ef9365e55bcbec8d3ee03a24ee9f410a784f1b5e42c358c399f0cdcdb030f9","cacheId":57}

Run of the tag

with:
  key: docker-layer-caching-SATTL-{hash}
  restore-keys: docker-layer-caching-SATTL-
  concurrency: 4
  skip-save: false
env:
  AWS_DEFAULT_REGION: us-west-2
  AWS_REGION: us-west-2
  AWS_ACCESS_KEY_ID: **
  AWS_SECRET_ACCESS_KEY: **
Root cache could not be found. aborting.
cscetbon commented 3 years ago

@satackey 👆 you probably have an idea of what is going on ?

jamie-wearsafe commented 2 years ago

@andre-lx and @cscetbon it might be due to the keys and restore keys being used. Try this:

    - uses: satackey/action-docker-layer-caching@v0.0.11
      with:
        key: docker-layer-caching-${{ github.workflow }}-${{ github.event_name }}-${{ github.head_ref || github.ref }}-{hash}
        restore-keys: |
          docker-layer-caching-${{ github.workflow }}-${{ github.event_name }}-${{ github.head_ref || github.ref }}-{hash}
          docker-layer-caching-${{ github.workflow }}-${{ github.event_name }}-${{ github.head_ref || github.ref }}
          docker-layer-caching-${{ github.workflow }}-${{ github.event_name }}
          docker-layer-caching-${{ github.workflow }}
          docker-layer-caching-

And see if it makes any difference.

japgolly commented 2 years ago

FYI I tried the above and it didn't make a difference

japgolly commented 2 years ago

Found a fix:

        with:
          key: docker-layer-cache-{hash}
          restore-keys: |
            docker-layer-cache-
            layer-docker-layer-cache-

Turns out that layers are saved with a layer- prefix (see here) that isn't used during cache restoration (see here).