Add github CI integration #27
Conversation
| uses: actions/cache@v1 | ||
| with: | ||
| path: ~/.stack | ||
| key: ${{ runner.os }}-${{ matrix.resolver }}-${{ hashFiles('stack.yaml') }} |
There was a problem hiding this comment.
The cache depends on xmonad-extras.cabal as well, as adding dependencies results in more built packages.
There was a problem hiding this comment.
We could. But I don't want to invalidate the cache because the resolver is still the same and we can use other parts of the cache.
But this current method will become inefficient if there is a huge amount of new packages newly to xmonad-extras.cabal. But I don't think that will happen (I could be wrong). So the tradeoff here is cache getting invalidated often for some changes in the cabal file vs no cache available for some of the newly packages added in the cabal file. I took the second tradeoff, but I'm happy to be convinced otherwise.
There was a problem hiding this comment.
But I don't want to invalidate the cache because the resolver is still the same and we can use other parts of the cache.
This should not be an issue with the restore-keys you use. It will just use the latest available cache for the given platform and resolver.
About the tradeoffs: I think you're understanding it backwards. Whenever the cache hits, it's not replaced at the end of the build, so by having less specific cache key, it will use cache with potentially missing packages, as adding a package to xmonad-extras.cabal will hit old caches. But when the cache doesn't hit, it just uses the latest available that still matches restore-keys and then stores it at the end of job.
None of this really matters for xmonad, really, but I noticed it so I pointed it out.
(Oh and you might want to use cache@v2 which is supposed to be faster thanks to zstd compression.)
There was a problem hiding this comment.
Ah, I see. Thanks, that does make sense. I will try to create a follow up PR unless someone beats me to it.
No description provided.