remove datestamp from bootstrap cache keys

[geekosaur]

The intent behind the datestamps was to avoid accumulating out of date source tarballs — which we've been doing since 2022, because nobody's been updating it.

Use a hash computed from the bootstrap JSONs instead, which will be self-updating.

---

Template B: This PR does not modify behaviour or interface

E.g. the PR only touches documentation or tests, does refactorings, etc.

Include the following checklist in your PR:

• Patches conform to the coding conventions.
• Is this a PR that fixes CI? If so, it will need to be backported to older cabal release branches (ask maintainers for directions).

[geekosaur]

EDIT: this comment is now historical; the first version removed the datestamp entirely, because nobody knew why it was there.

---

On second thought, I'm probably closing this in favor of adding a reminder to update the datestamp to things that update the bootstrap JSONs. The problem is that we'll accumulate older versions of source packages. (And probably already have such accumulation, since we haven't been updating the datestamp.)

Comments?

[geekosaur]

Actually, appropriate keys can be computed dynamically by using hashFiles on the bootstrap JSONs, so the next push will do that instead. Existing caches will be matched by restore-keys, in effect upgrading them without losing existing cached downloads.

[geekosaur]

Wait, if I save the existing caches we save 4 years of outdated source tarballs. Guess they just have to go.

[geekosaur]

Uh, anyone know if it's safe to swap the checkout and cache steps? Because it's kinda hard to compute a hash for a file that doesn't exist yet.

[geekosaur]

Hackage is "down" again, but at least the cache keys now work properly.