CI: caching: fix early termination expression check & cabal.project replacement#2520
Conversation
5459348 to
f63e0da
Compare
|
Ok. Now lets actually check the early termination & after that the new key (should go into full run). |
It is obscure bug. Details are in https://matrix.to/#/!oOjZFsoNYPAbTEgSOA:libera.chat/$tB_L6wbaxe1ElQtYzMI9woID4hZyscS6Rhpn-nsCc6Y?via=libera.chat&via=matrix.org&via=monoid.al Because after the second path somehow it always returned `False` - the caching runs always resulted in early termination.
In the https://github.com/haskell/haskell-language-server/runs/4596861600?check_suite_focus=true of haskell#2503 Noted that: I rm cabal.project. The sources of cabal-ghc921.project contain: index-state: 2021-12-18T00:00:07Z cp cabal-ghc921.project cabal.project Then from cabal.project CI retrieves finderprint 2021-11-29T08:11:08Z. Seems like GitHub uses alias cp=cp -i - preventing UNIX-like default copying over behaviour. & rm cabal.project does not remove the file. cabal.project seems to be protected from deletion.
Renewing cache.
53a05f3 to
6483ad2
Compare
|
I advanced the Which changes the key. So the old key of cache & new id for cache of the workflow does not align & so old storage is loaded, but the full build&cache process starts & then saves into the new key. Resulting into the proper long caching run: https://github.com/haskell/haskell-language-server/runs/4599160496?check_suite_focus=true |
|
Ok, now I need to wait until this run completes & then drop the modifications. & have a 1 clean run on |
|
Ok, now run is complete https://github.com/haskell/haskell-language-server/pull/2520/checks. By dropping the WIP commit - disabling |
6483ad2 to
e4076ed
Compare
|
Seems I checked everything about early termination this time. & seem that I hope we solved the main problems there & hope that soon we would exhaust hidden from us bugs in the CI to become sure in configuration robustness. |
|
Would note, that now because according |
Details are in the commit messages.
We not noticed the first specific of the CI, because the early cutoff behaved as it should. It was respected to return
'false'to terminate early, but that check always returned'false'. When working in GHC 9.2 PR could not force the caching build to start, because check that I fix - always skipped the steps (always returnedFalse). New check is done in the way how it is done in otherif: ... != 'true'statements in the workflow.The second specific is both Ubuntu-specific & maybe GitHub specific. Some OSes run
alias cp='cp -i'& when I tried tormmanually -cabal.projectappeared to be protected from simplermby setinning (most probably) of a "sticky bit" on$HOMEdirectory. I found that-out by working in GHC 9.2 PR (whereindex-stateis actually different between.projectfiles & noticed that CI cache key was with the same inferredindex-statein all jobs). Nowrm -fforced & that allows removing file with a sticky bit. log reports the situation of files changes there: https://github.com/haskell/haskell-language-server/runs/4597911492?check_suite_focus=true#step:14:460