-
-
Notifications
You must be signed in to change notification settings - Fork 378
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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
CI run completed successfully: https://github.com/haskell/haskell-language-server/runs/4599610364?check_suite_focus=true. |
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, good catches, thanks
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 torm
manually -cabal.project
appeared to be protected from simplerm
by setinning (most probably) of a "sticky bit" on$HOME
directory. I found that-out by working in GHC 9.2 PR (whereindex-state
is actually different between.project
files & noticed that CI cache key was with the same inferredindex-state
in all jobs). Nowrm -f
forced & 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