Daily index snapshot bump CI
- Dominant language
- Haskell
- Stars
- 1.7k
- Forks
- 750
- Avg merge
- 4d 3h
- Merged PRs (30d)
- 28
Description
Today, we do a fresh `cabal update` every CI run. This means every CI run is an adventure, because any one of our deps could have done an update that breaks us. Good: We find out when deps break us quickly, which is important because we should be responsive to such breakage. Bad: This breaks CI, which is disruptive for people who develop Cabal, and also makes it more difficult to find out what the error is, because you might not find out about the problem until days later when someone actually pushes to master or opens a PR.
Here is a scheme that we do for our OSS builds at PyTorch which seems to work pretty well:
- We have a daily job which builds the environment (e.g., pulls the latest Hackage index via `cabal update`) and runs a full CI build. If the CI build passes, it commits the index state into a repository. This doesn't apply only to index state; it can also apply to any configuration in the environment; e.g., it could be a docker image that gets committed on success
- Our actual CI builds don't use the latest index state; instead, they use whatever the latest state of this repository is.
Now, when there is an update to Hackage or GHC that breaks Cabal, the first job fails, and we DON'T update the state repository. We get a build failure notification which can be resolved asynchronously, but at the same time our CI keeps working. Furthermore, we can easily diff passing and failing builds and see what in the environment changed.
Contributor guide
Assessment
This issue has not been assessed yet.