The script runs under 'set -u' so we have to use "${SKIP_DCH:-}"
to make sure the script doesn't fail if SKIP_DCH is *not* set
(being the default usually).
We already check for 'true' in different settings, so let's keep
it homogeneous and use 'true' instead of '1'.
Also inform the user about when SKIP_DCH is being used to make
debugging easier.
Related to previous commit (201ec1e378).
In some cases it may be desirable to build a branch as-is,
without modifying the debian changelog. This patch allows this
by adding an option SKIP_DCH, which will skip running if set
to "1".
If we modify the changelog then the tag doesn't match its build
any longer. If we even modify the version number (adding stuff
like distribution names) then we either get a decreased or
increased version number compared to the tagged version. This
causes problems in several situations (without even considering
stuff like copying packages from one distribution to another one
where the added distribution name is misleading then).
Therefore just don't touch tagged builds at all.
The ArtifactDeployer isn't the prefered choice and there's
no reason to make BASE_PATH handling more confusing than necessary,
so just drop the userContent magic.
Not only git-dch, but (now?) also git-buildpackage refuses to operate
on a single git commit, too, so remove the temporary branch later in
the workflow, after git-buildpackage has been called.
We we can't do just a grep for "remotes/origin/debian when"
trying to check out the "debian" branch, instead we need to
check for a trailing '$' at the end of the grep string to
avoid matching e.g. remotes/origin/debian-lenny then.
Thanks: Axel Beckert
We can't use git-dch's auto mode if we've to deal with
a distribution being set to UNRELEASED because that fails
with:
| + git-dch --auto -S --multimaint-merge --ignore-branch --new-version=1.16.9~1343298526.109
| Changelog last touched at '6293f12440f48c1e245033801f151e4c99114db7'
| Continuing from commit '6293f12440f48c1e245033801f151e4c99114db7'
| No changes detected from 6293f12440f48c1e245033801f151e4c99114db7 to HEAD.
| dch: fatal error at line 984:
| New version specified (1.16.9~1343298526.109) is less than
| the current version number (1.16.9)! Use -b to force.
| dch --no-auto-nmu --distribution=UNRELEASED --newversion=1.16.9~1343298526.109 --multimaint-merge -- "UNRELEASED" returned 25
| Couldn't run ' dch --no-auto-nmu --distribution=UNRELEASED --newversion=1.16.9~1343298526.109 --multimaint-merge -- "UNRELEASED"'
So instead run dch with custom command line to get a
version number being smaller than the one that will be
released later on.
The checkout of the branch might be behind, so just use the
$GIT_COMMIT we get. This addresses situations like:
| + git checkout master
| Previous HEAD position was 6293f12... Bump version to 1.16.9
| Switched to branch 'master'
| Your branch is behind 'origin/master' by 426 commits, and can be fast-forwarded.
Use our "manual" way of identifying latest merge/tag (known
as identify_latest_change in the implementation) only if
invoked with cmdline option "identify", otherwise default
to git-dch's auto mode which does a better job in most situations.
While at it slightly refactor the identify_latest_change code
and also drop the "j" from git rev-list's --tag option.
Try to check out branches upstream, debian and pristine-tar
which are known to be common branches for building git
projects.
If environment variable $branch is set check out this branch,
otherwise fall back to $GIT_COMMIT as we used to do so far.
I'm still not entirely happy with this but I'm not aware of
anything better yet...
This brings generate-git-snapshot closer to what generate-svn-snapshot
already provided, jey.
Thanks: Raphael Hertzog <raphael@ouaza.com> for the suggestion
When moving Debian package builds from one CI system to another one
then the build number (BUILD_NUMBER) won't necessarily be the same
anymore. So do the same as in generate-svn-snapshot: include the
timestamp in the version string.
git-buildpackage should provide just the according magic like
building the orig.tar.gz, but dpkg-source should do the rest™.
This avoids running the 'debian/rules clean' step which might
include execution of insecure commands.
Disclaimer: So far this works fine for all the packages I tested,
let's see how well this works in the long run...
We already depend on dpkg-dev but don't have libparse-debianchangelog-perl
in our depends, so use in generate-git-snapshot the same command as in
the other scripts.
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$
Michael Prokop
Patrick Schoenfeld
Axel Beckert
Michael Prokop
Alexander Wirt