Having a bit of trouble getting the tests to work, I'm not super familiar with TS/JS, so if anyone could help me out getting tests written for the main logic change that'd be great.

@davidsbond I just sent you a PR on your PR. With that, the tests pass and your updates to the action can be run.

However, the underlying actions library will need to be updated to accommodate your changes.

You can see this here:

I think that with some creativity, we could get around this but I haven't figured that part out.

Hey @elizabrock thanks for the PR PR, I'll merge your PR into my PR :)

@elizabrock somewhere in https://github.com/actions/toolkit appears to be the place we'd need to make further changes

Having an initial look it seems like the constraint could be server side, so perhaps this is not possible

I'm currently using the patch and it seem to work great. Thanks for the work!

The problem with this is the the update flag needs to be specified before the cache is downloaded. It would be nicer if we could specify it afterwards. Imagine that the cache is caching the latest version of some downloaded source code. If the source code on the web matches the source code in the cache, use the cache. Otherwise, download the new source code and re-build it and cache that.

So the steps in my CI would be:

1. Download the cache.
2. Compare the version of the utility in the cache to the version on the web.
3. If the compare matches, set update to false. Otherwise true.
4. Also, if the compare doesn't match, re-download and rebuild that utility.
5. Do the rest of the CI.
6. In the Post-CI action, obey the update flag as needed.

There's no way to do this with the update flag as explained above because the need to update isn't known until after the cache is downloaded.

Unfortunately this does not work for me (anymore?). It fails with the following error: Unable to reserve cache with key build-ubuntu-ccache, another job may be creating this cache. I think the problem is already documented here: actions/toolkit#505

I'm seeing that error, too. Seems like a new error? Maybe something is broken with the underlying cache?

Did it used to work? I thought that it worked at one point...

Having an initial look it seems like the constraint could be server side, so perhaps this is not possible

I agree with this. When you want to upload to the server, you need a cacheId which the server gives you. The server returns a cacheId of -1 when you try to reserve a cacheId that already exists. I'll keep looking into this.

@eyal0, yeah. I'm surprised by reports from people that this works. As from my comment last year it looks like they have a constraint server-side on cache keys. None of the maintainers have done anything with my PR and issues, so I think it's unlikely for this feature to get picked up. We'll have to wait and see.

Maybe it was a fluke and it used to work and it stopped working? Or maybe it would only work on the first time so it appeared to work. Also, I think that it will work if the cache gets cleared out in some other way, like maybe the cached entry expires.

Anyway, if the server won't co-operate then this will be difficult to do! It might be at the server has some hidden command to delete a cache entry. We could delete it before trying to reserve a cacheId for a new one. But how would we ever discover this secret command?

I guess that another solution would be to add a random suffix to key. That would allow it to upload. The trick would then be to disable uploading if the cache was found, because you don't want to upload every run and waste time and space.

@davidsbond Here's my workaround: #498 (comment)

Kind of a hack but I think that it's working.

What's the reason it has been closed?