On Friday, 04.03.2016 at 14:57, Antti Kantee wrote: > Sounds a bit backwards to have the master list in .travis.yml. Could we > instead have a top-level Makefile, and Travis would pick up the packages > from there? Some blacklisting feature might be necessary.
Unfortunately the list has to go directly in .travis.yml, since each package is built as a separate build job and thus needs a subkey defined under 'env:'. A top-level Makefile wouldn't help here since you'd still need to list make PACKAGE=foo individually in .travis.yml. > A top-level Makefiles (or a similar construct) would be useful for "bulk > builds", for cases where someone wants to locally build all packages. We do have a (very simplistic) top-level Makefile which builds everything if you run 'make'. > I'd much rather see the script committed to rumprun-packages, e.g. to a > directory called "_meta" (or whatever better name someone can come up with). Ok, committed as .travis-trigger.sh ITMT. Feel free to move it when we have more such scripts. > I think we now need a policy for packages which do not build -- I don't want > to perpetually advertise a broken build in case there's a package that > nobody wants to fix in a reasonable amount of time. We could just mark a > package broken the first time it fails to build, file an issue, and remove > the broken tag once the package is suspected to be fixed; rinse+repeat. The > fancier option to list packages which are known to be broken and don't > affect the 0/1 build result, but nonetheless we keep on building the broken > package. The latter gives us finer-grained detection of regressions, but > requires more work. I'd just go with the first option for now. Thoughts? The main problem with this approach (removing a failing package from a build) is that right now there's no easy way for a maintainer to test that their package builds *on Travis*. This is relevant for e.g. the currently-failing OpenMP package. Asking maintainers to fork the repository, set up a Travis account and run their own builds is suboptimal. IMHO the best thing to do would be to eventually change to a Dockerized build with one "build container" per package, that way at least anyone with Docker installed can replicate a build locally (or anywhere with Docker). The reason I've not done that yet is because I wanted something that works ASAP and doesn't depend on anything except Travis. Thoughts?
