Another job might place its files into the incoming directory at
the same time. If the *.changes file is present but not all its
referenced files are there yet this causes an error in the
reprepro call and therefore forcing the Jenkins job to fail.
Otherwise we can't reliably handle release builds, since we might
have packages that are already registered in another distribution.
Therefore provide release builds in a specific directory, this
also allows to move the given release to another place easier.
Do not assume we always have a master branch, instead consider
$branch if it's set and use master branch as fall back only.
Also checkout the branch instead of just creating a local version
of it. This takes remotes/origin/* into consideration, so the
user shouldn't have to specify remotes/origin/ at the beginning
of branch names any longer.
For some reason the Git plugin in Jenkins doesn't run the
'git pull' for us, so while the files are fetched already
they aren't present in the working directory yet.
So let's make sure we actually have the files we're claiming
to work with.
Thanks to Raphaël Hertzog for spotting the issue
when investigating build errors in dpkg's Jenkins job.
JFTR:
| jenkins@grml-jenkins:~/jobs/dpkg-source/workspace/source$ git pull
| Updating fb18783..91495b8
| error: Your local changes to 'debian/changelog' would be overwritten by merge. Aborting.
| Please, commit your changes or stash them before you can merge.
| jenkins@grml-jenkins:~/jobs/dpkg-source/workspace/source$
When a foobar_0.42.orig.tar.gz is found then debian/control isn't
present necessarily, so make sure we don't try to access debian/control
if it's not available.
For the timestamp we're now using seconds since 1970 (date +%s).
This will always increase over time whereas svn revisions might
not be consistent over all the time and building on slaves might
cause lower build numbers.
So lets use ...~${TIMESTAMP}.svn${SVN_REVISION}.${BUILD_NUMBER}"
as the version schema to get increasing version numbers no matter
what.