"The cache will never get invalidated" when lock file is missing

[karlicoss]

I tried using setup-uv action with my project, and it worked great! https://github.com/karlicoss/cachew/blob/95af60ac93b55982828750c8c29121f40bfec303/.github/workflows/main.yml#L42

However, I noticed this warning:

No file matched to [**/uv.lock,**/requirements*.txt]. The cache will never get invalidated. 
Make sure you have checked out the target repository and configured the cache-dependency-glob input correctly.

I indeed don't use a lock file, so makes sense that it can't use anything as a cache key.

The docs are very clear about that, and I guess I should just use enable-cache: false (I'm using Github-hosted runners)

However I'm wondering if falling onto 'empty' key is a reasonable default?

IMO it's much less surprising/error prone to disable cache altogether if there are no files to use as a key. If the build is too slow due to no caching, someone would notice/complain and the developers will figure it out. But if the empty key is used as it's now, it would result in running CI on old versions of dependencies, which feels harder to debug and more annoying.

Thanks!

[eifinger]

The cache still works. Disabling the cache would make running your workflows slower.

The cache key is used to determine if the cache contains outdated dependencies and should be invalidated/discarded.

If you update your versions (in a way which leads to an empty cache key) the cache will contain the old and the new versions. It will NOT only contain the old version and make anything hard to debug.

[karlicoss]

Ah thanks!

the cache will contain the old and the new versions

So does this mean the only issue here is that the cache might overflow? And since the key the same (empty), Github would prune both "old" and "new" cache when it overflows?

Looks like for github hosted runners the cache limit per repository is 10GB (and it's cleared after a week) https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/caching-dependencies-to-speed-up-workflows#usage-limits-and-eviction-policy

So it would only be an issue if you have tons of pipelines that update versions really often? I guess it's possible if many people are working on many branches not necessarily up to date with master.

I guess another issue is that the cache would grow in size (up to 10GB limit), so you might end up restoring 10GB from cache even though you don't need it?

[eifinger]

Yes, to all of the above.