For some of my projects I'd like to test the ability to generate a package from every upstream commit.
In the past I've encountered two types of problem: a) upstream makes some change (e.g. leaving some new header out of their distribution tarball) or something else that is only discovered after they release a new version b) something else changes in unstable (e.g. somebody uploaded a new version of a reSIProcate dependency just a few days before I made a reSIProcate release, this would have been a much easier thing to deal with before I made the upstream tag) and I feel that making regular Jenkins builds of the packages, possibly for every upstream commit and every dependency change in unstable, would help detect problems sooner and usually at a point in time when it is easier to resolve them. Has anybody looked at using travis-ci or any other cloud platform to automate such testing of upstream commits? Is there any standard way of setting up Jenkins to do this? In most cases, I can also get the debian/* files into the upstream repositories. Can anybody comment on how the debian/changelog should be maintained if making such builds automatically? In particular, what format should be used for the version numbers if building from Git commits? For some of the packages, there are a set of related dependencies, e.g. to build postbooks, I first need to build the latest openrpt and csvimp and install their dev packages. So the Jenkins server may need to create the openrpt packages and publish them to a local apt repository and then use sudo to install them when it wants to build postbooks. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54eedb6f.60...@pocock.pro