Is there some way we can prevent this from breaking? Maybe a test that checks that this is the only file changed?

Why would this file invalidate the cirrus cache? Aren't we fingerprinting bin/internal/*.stamp?

Ahhh.. do we use this in the tool to say we don't trust the cache?

I know the shell wrappers don't check it. It looks to me like this is just used for how often we show the user about a newer upstream version.

Other than making it readonly, I can't think how. bin/cache is gitignored so there's no way to tell what's changed in the working directory. Creating a sub-repo in that directory in setup to then reset before upload would take minutes to init and commit because of the large binaries.

#44526 would make this better.

Why would this file invalidate the cirrus cache? Aren't we fingerprinting bin/internal/*.stamp?

The cache invalidation doesn't come from the fingerprint, it comes from Cirrus's hashing of the cache. From https://cirrus-ci.org/guide/writing-tasks/#cache-instruction

After the last script instruction for the task succeeds, Cirrus CI will calculate checksum of the cached folder (note that it's unrelated to fingerprint_script instruction) and re-upload the cache if it finds any changes. To avoid a time-costly re-upload, remove volatile files from the cache (for example, in the last script instruction of a task).

ahhh, i see. thus any changes of the cache during execution will trigger a re-upload.

@Hixie @dnfield Do either of you know why the other shards have separate Cirrus caches for pkg and artifacts in the bin/cache but not that entire directory? I don't think the Linux or Windows caches are getting used since all the stamps are missing and it just re-downloads everything again.
Example:
https://cirrus-ci.com/task/6607166220009472?command=setup#L420

I think that's just how they were always set up - it does look like we're getting cache hits (https://cirrus-ci.com/task/6607166220009472?command=flutter_pkg#L16) but maybe failing to use them in setup...

It seems likely to me that this worked at some point and we fixed something in the tool that broke it.

Yeah, even worse than ignoring the cache, we're downloading it, then the tool blows it away because the stamp files aren't there and re-downloads them. Should this PR include linux + windows?

I was going to do Windows and Linux in a separate PR. I want to get the mac changes out the door ASAP with Cirrus's network flakiness.