cabal-*.project: index-state +1s

[Anton-Latukha]

It is made to fix the current situation, for example, if Caching workflow in master got canceled for some reason, on a successful run of the action in the workflows - workflows still runs the post-hooks that actions have, which would cache & share the cabal store of the canceled workflow.

On merge, this change would refresh caches, which should fix Windows build waits.

[Anton-Latukha]

Ok. It currently fixes the cache situation for the time being.

In https://github.com/haskell/haskell-language-server/runs/4584037502?check_suite_focus=true we see that for Windows build the input (partial) cache was at 110-150Mb, & the output (full) cache is 203-300Mb.

[Anton-Latukha]

As we agreed on in the chat room https://matrix.to/#/!oOjZFsoNYPAbTEgSOA:libera.chat/$-Wv69VWdRDLGm-KNPvn5HkCGdRAwd1Ygk1601yE8db0?via=libera.chat&via=matrix.org&via=monoid.al.

[jneira]

Maybe it is a minor thing but with non existent hackage index timestamps all builds logs:

Warning: Requested index-state 2021-11-29T12:30:08Z is newer than
'hackage.haskell.org'! Falling back to older state (2021-11-29T12:28:17Z).

which is a little bit annoying.

I see the advantage of using artifical index state to invalidate cache but maybe we could update to the last index state given by cabal update
I mean we will have to update it sooner or later and ci will tell us if there is something wrong so we can try to find an older one.

[Anton-Latukha]

1. The timestamp was reverting to 2021-11-29T12:28:17Z before also. In fact, that is why +1s - changes literally nothing, except running cache update, as cabal still uses the last discrete Hackage snapshot 2021-11-29T12:28:17Z.

2. If I to update Hackage index not +1 second, but +1 908 282 seconds (~ time from that snapshot) - it is a bit other thing, and has all sort of bigger consequences - contributor would need to be ready & address all kinds of development updates - which expands the scope from fixing the cache for the project - to opening a number of reports to a number of places & asking people about syndromes, doing the project dependency update without discussion is that update desired in the first place - & so 1) that PR would be harder to do & 2) harder to pass review on 3) agenda of PR initially was to fix caching to continue work on the situation, it changes the scope and focus of the work overall.

PR just wanted to fix the caching situation for everybody.

Even the work on updating the index-state pinning to the current one - would be faster having the Windows cache restored before that.

[jneira]

ok, let it be +1, we will end to have a real one anyways and the actual one emits the warning, thanks for fixing cache

[Anton-Latukha]

Thank you.

I just was focused on the other thing in this PR & was not prepared to change the scope.

[Anton-Latukha]

Superb, workflow finished: https://github.com/haskell/haskell-language-server/runs/4591215047?check_suite_focus=true