On e.g. Ubuntu "sid" isn't supported, so we can't just hardcode it.
Instead support setting COWBUILDER_DIST via /etc/jenkins/debian_glue
and if it's not set then use "$distribution" if it's set, otherwise
default to the currently running distribution and just fallback to
"sid" if none of all of that worked.
Thanks: Daniel Thomas for the detailed bugreport
Quoting Brian:
| The other change I made in build-and-provide-package, was to
| automatically do a binary-only build if the arch specified does not
| match the main architecture and/or the architecture of the host:
|
| http://pastebin.com/mhJGHpV5
|
| Otherwise, both my amd64 and i386 configurations build with the
| default "-sa" build option, each generating a changes file that
| references a .dsc file with a different checksum. I'm thinking the
| best approach long term might be to have the -source job actually
| upload the source package to reprepro leaving
| build-and-provide-package to always just build with -B. Your
| thoughts? In the meantime, I've just made the change above.
|
| It looks like you were addressing the problem on your end as well with
| (I can see it executed in your dpkg jobs on http://jenkins.grml.org):
|
| if grep -q '^Architecture: all' "$control_file" ; then
| if grep -q '^Architecture: any' "$control_file" ; then
| echo "*** Package provides arch 'all' + 'any', enabling -B
| buildoption for this architecture. ***"
| # -B -> binary-only build, limited to architecture dependent packages
| DEBBUILDOPTS="-B"
|
| However, this code won't work as intended if, for instance, a control
| file contains:
|
| Architecture: i386 amd64
Thanks: Brian Thomason <brian.thomason@eucalyptus.com> for the initial patch
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.
'${release}' is a hidden bomb: when provided through predefined parameters
from an upstream jenkins job (like foo-binaries receiving the parameters
from foo-source) but the job (foo-binaries) gets triggered manually (without
setting the predefined parameters therefore) then ${release} is set to
'${release}' instead of being empty
If you want to have TRUNK_RELEASE enabled by default but skipping certain
builds, e.g. if you're building tagged or branch builds then you can easily
skip inclusion of such builds using something like:
case "$branch" in tags/*|branches/*) export IGNORE_RELEASE_TRUNK=true;; esac
Support setting PROVIDE_ONLY for skipping cowbuilder stage
and BUILD_ONLY for skipping reprepro repository stage.
Drop REMOTE_REPOS configuration variable, as the name actually
doesn't reflect what the script supports nor is it of any use
in the main configuration file when having PROVIDE_ONLY and
BUILD_ONLY available.
This provides the base for using $job-source, $job-binaries and
$job-repos to get the build process scaling and distributed on
specific slaves.
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 can't remove a package from the repository in the step where
we're checking for missing binary packages (to get rid of packages
which are no longer provided but shouldn't stay in the archive)
if the package is an 'Architecture: all' one, as e.g. the i386
build might remove the package from the amd64 build.
So let's check for "-B" in DEBBUILDOPTS and then skip the removal
process in such a situation...
If we're building a package version where Debian's build tools
don't automatically consider it as new upstream version and therefore
don't include orig.tar.gz into the upload the build process fails.
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.
If we switch the directory we might end up in the wrong directory
for further actions, so run all the commands around svn-buildpackage
in a subshell.
Also replace the --svn-move command with --svn-move-to to place
the artifact files in the original directory, otherwise the files
might be placed in the wrong directory if $branch is set and used.
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.
Michael Prokop