On 03/03/16 16:14, Martin Lucina wrote:
Hi,
I've implemented Travis CI builds for rumprun-packages. After fixing
trivial issues with some packages, all[1] packages except openmp are building.
See the latest results here:
https://travis-ci.org/rumpkernel/rumprun-packages
Awesome.
Notes for maintainers / new package authors: (I'll add these to README
shortly)
1) When adding, removing or renaming a package ensure that you make the
corresponding update in .travis.yml.
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.
A top-level Makefiles (or a similar construct) would be useful for "bulk
builds", for cases where someone wants to locally build all packages.
2) If your package requires any additional host dependencies to build which
are not installed in the Travis "trusty" CI environment, you will also need
to modify .travis-install.sh and add the appropriate "sudo apt-get
install".
IMO we should not encourage host dependencies. Even the current ones
are not really optimal, but someone would have to fix them, and the
value of autobuild by far outweighs the "incorrectness".
[3] There is one trivial external dependency, which is the shell script
running as a cron job on my server to trigger the builds using the API
calls documented above. I can send a copy of this to the list if anyone
wants it.
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).
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?
Enjoy,
Thank you!
