Update Travis CI script #254
Conversation
I need to investigate whether that's a cabal bug or a bug in PS: I'm confident it's a |
The symptom was that `cabal sdist` would rightly fail with ``` Building source dist for network-2.6.3.2... cabal: can't find include file HsNetworkConfig.h ``` Instead, the proper way is to inject autogenerated C header files via .buildinfo (which is generated at `configure`-time).
|
note to myself: cabal should warn about files from the |
|
hrm... this may be blocked by #245 (or alternatively, by |
|
@hvr Do you have any resources on |
|
@eborden As for |
|
|
||
| - compiler: "ghc-7.8.4" | ||
| # env: TEST=--disable-tests BENCH=--disable-benchmarks | ||
| addons: {apt: {packages: [ghc-ppa-tools,cabal-install-head,ghc-7.8.4], sources: [hvr-ghc]}} |
There was a problem hiding this comment.
I have some concerns about utilizing cabal-install-head. We shouldn't really be testing against a product that is not in circulation. Does a cabal-install-stable exist? An alias for the latest stable release.
There was a problem hiding this comment.
That's got to do with the issue that cabal new-build is quickly progressing so the not even yet relased stable 2.0 version is already somewhat obsolete regarding new-build, and the agenda here is to get as many real-world projects to help us iron out issues in cabal new-build so that we can make it the default sooner. The currently funded summer-of-haskell project to get new-build ready to replace build is focusing on HEAD too.
IOW, I'm basically using cabal-install-head rather than cabal-install-2.0 (which is also not yet a released version!) in order to increase the dogfooding of cabal to help cabal's development. We're running 2 years late, as new-build should have been available already in June 2015 ...
There was a problem hiding this comment.
I'm reticent to follow this path. The responsibility of network's CI is to ensure the package builds and is correct for its users. If its users are using new-build then that is fine, but the other motivation introduces a second purpose for this CI (testing cabal for the cabal developers). I'm less comfortable with that second motivation. It seems the cabal developers need their own CI environment for this purpose.
@kazu-yamamoto How do you feel about this?
There was a problem hiding this comment.
I see what you mean, but I'd point out that you seem interested to test an unreleased GHC 8.2.1 (of which we offer pre-releases primarily to help us with development and crowdsource finding bugs in GHC to help ensure that the final release is as bug-free as possible), and yet you don't want help test an unreleased cabal...
It seems the cabal developers need their own CI environment for this purpose.
Unfortunately, I don't see anyone stepping up for writing such a CI environment for cabal. Although we do have a rather large CI system already in place which uses up hours(!) of cputime per commit (this is btw the reason why the haskell github-org travis jobs sometimes take so long to start: it's because cabal uses up the time-budget), but it only catches regressions, and you can't test enough. So we just like GHC, depend on crowdsourcing to get a better test-coverage.
There was a problem hiding this comment.
Well, the motivation behind testing 8.2.1 and GHC-HEAD are to stay ahead of the curve and anticipate breakage from GHC. I don't really intend it as testing for the GHC team, but a canary for network.
| @@ -1,94 +1,98 @@ | |||
| # This file has been generated -- see https://github.com/hvr/multi-ghc-travis | |||
| # This Travis job script has been generated by a script via | |||
There was a problem hiding this comment.
This represents a fairly large change set. network's CI was steaming along nicely before. Could you please provide some motivating information to merge these changes.
Some open questions:
- Why is this better?
- Why has the script changed so drastically?
- Should we be utilizing
new build? The plan is to replacebuildwithnew-build, so wouldn't this script remain more stable with justbuild?
There was a problem hiding this comment.
- Why is this better?
- Why has the script changed so drastically?
Simpler and less fragile/cumbersome caching logic; the old one was a shell-script hack that would break in some cases. new-build now does this natively and more principled and doesn't break easily when reinstall-situations occur.
Also the new script tests the sdist which helps catching packaging bugs (i.e. this exposed the HsNetworkConfig.h bug).
- Should we be utilizing new build? The plan is to replace build with new-build, so wouldn't this script remain more stable with just build?
The thing is that what is currently called cabal build is a discontinued feature; and I don't use it myself, and I don't have the bandwidth to care about any bug reports related to cabal (old-)build. All focus is currently on getting cabal new-build out of the door, which uses a totally different paradigm. I'm generally trying to get everybody off my old version 1 script (which I hardly maintain anymore), in favour of the new version 2 script which is the one that generated the .travis.yml script here.
There was a problem hiding this comment.
Is cabal build officially deprecated? Does it produce warnings on the latest stable version of cabal?
No description provided.