using cache on tags does not work

[hq9000]

hi!

I have a cache created on a non-default branch, all works fine except when the workflow is run on a tag, the cache isn't hit

when it's not a tagged commit, and my github.ref is "...heads" it starts working again.

I guess it's related to https://github.com/actions/cache#cache-scopes

Essentially, it looks like there is no way to use cache in runs on tagged revisions, or is it? (I don't have any caches on my master yet). Is it an intended behavior?

At least, it'd be good if it was described in readme in that "scopes" section.

[lwj5]

I'm facing the same problem.

Our YAML

https://github.com/invoiceninja/dockerfiles/blob/1f7458c9f7b86935215b907c0a60f58b436f8785/.github/workflows/build_push.yml

The container is built upon tagged releases, and we cannot retrieve the cache when there is a new release with a new tag.

Is there a way around this? Or can a feature be introduced to rescope the cache?

[matheusnascgomes]

I also have a similar workflow to the one aforementioned by @lwj5 and facing the same problem.

[llamojha]

I'm also facing the same issue. Most of the workflows are triggered by tags and the cache size appears to be 0MB

[grafolean]

I believe I am having the same issue. Cache is reported as saved:

However, a tag + release on the same commit a few minutes later doesn't find the cache, even though the key is the same:

When I try saving and restoring the cache using on: [push], it works:

(note that restore-keys, while used here, did not improve outcome in the first example)

This issue is important because I usually use tags to mark the releases, and build + deploy only happen for known versions. While there are workarounds (for example using Docker Hub for caching) this approach seems very elegant and generic, so I would prefer to use it if possible. Is this a technical limitation of the caching system or just a bug that might be fixed? If so, are there any plans to do it?

EDIT: testing further, it seems like (on tag/release) cache is not saved, but can be loaded. In other words, it is possible to save cache on push and load it on tag/release.

[ManuLpz4]

Some update on this? 👀

EDIT: testing further, it seems like (on tag/release) cache is not saved, but can be loaded. In other words, it is possible to save cache on push and load it on tag/release.

[dharrigan]

This is a real problem for us. We are attempting to use github actions to perform our CI builds, including building docker images. Some of our docker images are massive - like gigabytes in size.

We indicate a release by tagging the repo and pushing the tag to trigger a build. There are zero changes in the codebase, indeed the git sha is identical before and after tagging the repo - yet, the build cache fails to find the previously cached files even although the cache key is the same, i.e., building on master just prior to tagging a release:

key: project-buildx-${{ github.sha }}
restore-keys: |
  project-buildx-${{ github.sha }}
  project-buildx-

produces a cache key similar to this project-buildx-c0c93837ce20676303c77dccf35c4c69e0b432e9

yet, when we tag the same repo, same branch - with zero changes, that kicks of a release build, the cache step reports Cache not found for input keys: project-buildx-c0c93837ce20676303c77dccf35c4c69e0b432e9, project-buildx-!

As you can imagine, this is causing a huge amount of fustration since the image was previously built and cached against the key, yet just by tagging the repo, on the same branch, the cache is not found with the same key - thus kicking off another build of very large docker containers - eating up lots of precious github action minutes - minutes that could have been saved, since it was built (and supposingly cached) just a few minutes earlier!

Please can something be done to address this - at least allow the same cache to be found against the same key when tagging the repo - that has zero changes (sha is the same).

Thank you very much for your consideration.

-=david=-

[just-seba]

We are also facing the same issue. Our release workflows are triggered by tags and the cache the cache step reports Cache not found for input keys: ...

[richardscollin]

I discovered a bit of a hacky work around. If you tag a commit with 2 tags e.g 'latest' and 'v1.0.1' then you can perform the github action against the 'latest' tag. When you want to make another tagged push, delete the 'latest' tag on the remote git push --delete origin latest, delete it locally git tag -d latest and tag your new commit with 'latest' and the new version.

Because it's scoped by tag you're still performing the action against the same latest tag.

[2sem]

or I want to write a multiline input into workflows_dispatch. I need it for release notes.

[willbicks]

Since building when a release is tagged is a feature described / recommended in the docs, and is also needed for other steps like docker/metadata-action, it's definitely annoying to not be able to cache when actions are implemented in this way.

Some potential solutions (from someone with no knowledge of the reasons for the current design) would be:

1. Scope the cache to the primary branch when the workflow is triggered by a tag.
2. Scope the cache to the branch associated with the tagged commit (challenging because the commit could be associated with multiple branches).
3. Add an option to actions/cache that allows cache keys to be scoped to the repository level instead of the branch level.

[hendrikmaus]

I'd add to that list a way to define a regular expression to match on previous tags.

Since most tags are created using a particular ruleset, one could tell the cache action to go backwards in time from tag to tag, matching an expr. (e.g. .* would match all), until a cache is found.

And yes, if no tag is found, a cache from the repo main branch should be preferred over any feature branch.

FYI: for the time being, I created a quick and dirty workaround in https://github.com/hendrikmaus/custom-cache-action It is independent from the native caching and uses GitHub Packages and a container image to leverage built-in storage. It is crude, but very hackable and flexible.

There is also a blog post on the concept https://blog.hendrikmaus.dev/github-actions-release-caching/

[constgen]

Do we have any official answer from the Github Actions Team? This issue is a real quota killer.

[Phantsure]

Creating cache on main Getting a cache hit on a release tag created from main branch

Either the issue seems to be resolved with v3 or it is specific to docker builds. Did anyone face this issue with actions/cache@v3 ?

[richardscollin]

Maybe the behavior is as designed, but I'm still encountering the cache not being sharable between different tags. For example a cache created on tag v1.0.1 will not be usable for tag v1.0.2. To me the expected behavior is that the cache from one tagged commit should be usable by another tagged commit if the cache key is the same.

[Phantsure]

@richardscollin Cache is usable by the child branch. If a cache is made on main branch all child branches, including tags from main would be able to use it. In your example, tag v1.0.1 and tag v1.0.2 are sibling tags/branches so sharing of cache is not possible. Does that answer your question?

[grafolean]

@Phantsure

Cache is usable by the child branch. If a cache is made on main branch all child branches, including tags from main would be able to use it.

Are you referring to some official documentation regarding this? If so, could you please share a link?

[Phantsure]

@grafolean Here is the docs referred https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#restrictions-for-accessing-a-cache

[richardscollin]

Those docs don't mention git tags, just branches. If the current behavior is as designed then I think a note/warning should be added in the readme here. Currently it states:

The cache is scoped to the key and branch. The default branch cache is available to other branches.

I believe it should mention tags in someway because it seems it's actually scoped by the tag as well, which differs from the existing description. The more detailed docs linked by the readme also do not mention the unexpected behavior for tags.

Given the current caching behavior, if you have a workflow file like the one below you will never be able to make use of caching:

name: test-cache-behavior
on:
  push:
    tags:
      - v*

Personally, I've stopped using git tags and just using a workflow file that triggers on every commit because of the current behavior.

[Phantsure]

@richardscollin It is true. Workflow file like above cannot make use of cache. Save cache is used mostly in a workflow which triggers on more frequently like push or pull_request and cache hit can work on tags/releases.

We will update the docs to call out the behaviour of tags you have faced. Closing this issue for now.

[grafolean]

@Phantsure Just to be clear, this issue is not solved yet.

It would be great if you could leave it open so that someone could post here once either the documentation is updated or behavior is changed.

[Phantsure]

Sure @grafolean. Re-opening this issue for now then

[richardscollin]

@Phantsure thank you for taking the time to review this issue.

[grafolean]

Sure @grafolean. Re-opening this issue for now then

Thank you @Phantsure, appreciate it!

[bishal-pdMSFT]

Given the current caching behavior, if you have a workflow file like the one below you will never be able to make use of caching:

name: test-cache-behavior
on:
  push:
    tags:
      - v*

@richardscollin as @Phantsure mentioned earlier, a tag trigger run would be able to use caches created in the base branch. This I think is a fairly reasonable thing as usually there would be CI runs happening on base branch and hence a reusable cache would exist in most cases when a tag is created.

The other case is for example v2 tag using cache from v1 tag. That is not supported on same lines as two sibling branches not sharing cache. Though I do agree that the cache poisoning problem which is associated with branches and PRs are really not that much serious for tags as tags creation needs more privileged permission.

[Phantsure]

@grafolean @richardscollin We have updated the docs to call out the behaviour: https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#restrictions-for-accessing-a-cache

[Phantsure]

Closing this issue as docs are updated