should the default environment cache key have the current date?

[zacharyburnett]

I would think the default cache key should be tied to the date in some way, so as to prevent the cache from becoming outdated. if this is an intentional design decision I can construct my own cache key

[jonashaag]

The cache is invalidated by the environment file.

[zacharyburnett]

The cache is invalidated by the environment file.

Indeed, if the file changes, but if creating an environment from the same file at a later date, then if any packages had new releases in the meantime then they would be outdated in the cache; is this intentional?

[jonashaag]

I see, in that case the cache will be invalidated only when GitHub deletes it (I think after 7 days?). I wonder if there is any good invalidation policy based on date that we can make a default.

[pavelzw]

There are cases where you don't want to tie the cache validity to the date, for example when using lockfiles as your environment file.

I'm not sure which option is better, though. Adding some kind of check if we use a lockfile or a regular environment file would lead to further complexity of the action, something that I would like to prevent if possible.

I think after 7 days?

After 7 days not being used or after 7 days in general?