Bump stack.yaml.lock

[philderbeast]

Minor glitch with #689 that slipped by me, the stack.yaml.lock file was out of date or rather I was testing a matrix of GHC = {9.8.2, 9.6.5, 9.4.8} but had forgot to update the resolver to match in stack.yaml that was for ghc-9.8.1.

$ cat .github/workflows/stack.yml
...
          # Reminder to also update the lock check.
          - {ghc: "9.8.2", stackage: "nightly-2024-05-25"}

$ cat stack.yaml

resolver: nightly-2024-01-26
...

~@facundominguez do you think we need to check for this in CI?~ I went ahead and checked the resolver and the lock file.

[philderbeast]

The lock check output when there's a difference.

diff --git a/stack.yaml.lock b/stack.yaml.lock
index fe80246..3856c80 100644
--- a/stack.yaml.lock
+++ b/stack.yaml.lock
@@ -5,12 +5,12 @@

 packages:
 - completed:
-    hackage: rest-rewrite-0.4.2@sha256:4afd57aaad716827485240428c1deb5a60b81a3c069968f3b0f27a3cb9faf247,3929
+    hackage: rest-rewrite-0.4.3@sha256:915fb98b8c0a0f518c1a4b75bcf3ae27a3ebd5b10d60cc16a216c2fca2148ab0,3929
     pantry-tree:
-      sha256: a72c2400f09a609d891198b8df1360dd9b50d2fd9d3628a887b04b24636e6401
+      sha256: 4de44fbeb7bd655caeafe605406c0bc5fe1788d9cf37cdac2f18b018ee4cf5e6
       size: 4075
   original:
-    hackage: rest-rewrite-0.4.2
+    hackage: rest-rewrite-0.4.3
 - completed:
     hackage: smtlib-backends-0.3@sha256:a947aead99f6a314833bddca9b502d5faea8d3bd2fc76ffb53c34d5c5b7557bc,1211
     pantry-tree:
@@ -40,12 +40,19 @@ packages:
   original:
     hackage: store-0.7.18
 - completed:
-    hackage: store-core-0.4.4.6@sha256:37d4a628785b72dd26f0d8565895d01f36b4a7b2539100d735c239cf12d76b53,1489
+    hackage: store-core-0.4.4.7@sha256:a2ea427ff0dde30252474dcb0641cb6928cb8a93cd5ee27d4c22adba8e729683,1489
     pantry-tree:
-      sha256: da7e56dce68e291ea431b552a5cbc7cb0736296f9436e339931b193d48072e68
+      sha256: 67828df739695d14f81cd572a3085c76f65ac75f8417095afef8dfb2815f523e
       size: 271
   original:
-    hackage: store-core-0.4.4.6
+    hackage: store-core-0.4.4.7
+- completed:
+    hackage: tasty-1.5@sha256:8da3f47fff790714f7d676692f1207aac156b41f705c55f14d1d8147a751264b,2787
+    pantry-tree:
+      sha256: d139b379075ff0204ad2aa2e20ba668534b21d03f8d712077e03e6d9294b2b8f
+      size: 1944
+  original:
+    hackage: tasty-1.5
 snapshots:
 - completed:
     sha256: 876a5c75d90718add42e1ad36d66000bf35050ce1c66748119897a32df613186
Error: Process completed with exit code 1.

[philderbeast]

The resolver check when it fails:

[facundominguez]

I went ahead and checked the resolver and the lock file.

Actually, I'm not sure I understand the purpose of the lock file in CI.

If the lock file is only needed to generate an accurate cache key, it could be generated with --dry-run before fetching the cache (similar to this setup). Is there a good reason to keep it version controlled?

[philderbeast]

The stack.yaml.lock file is commited to source control to help humans. As for the lock file in CI, I've done a bit more reading of the Stack docs, on lock files and the --lock-file option. You're right, I need to review the caching for this pull request, especially in light of https://github.com/haskell-actions/setup/issues/86.

[philderbeast]

@facundominguez I didn't yet try a run to see if these changes speed things up by restoring from the cache. Looking at the runs before and after the merge, there doesn't seem to have been any speed up.

[facundominguez]

hm, the jobs after merging don't find the cache, even though they use the same key used to upload it.

[facundominguez]

I have some recollection of caches being kept separate per branch. Probably rerunning the jobs in develop will find them.

Update: restarting finds the caches, but there's still no speed up. Much dependencies seem to be rebuilt anyway.