building packages of upstream commits with Jenkins

[Daniel Pocock <daniel@pocock.pro>]

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.