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.
If we have a package named ngcp-templates-ce-hylafaxplus then
this will match within the string ngcp-templates-ce-hylafaxplus-iax
and therefore will be skipped as in the missing_packages list.
So make the grep match only leading and trailing white space characters.
In the dcmd(1) listing there are also dsc, tar.XX and changes files
included, no need to run the binary removal for them as they either
don't exist or are duplicates.
There's no need to report what settings would be chosen for
executing cowbuilder if we're interested only in the
repository step, so just skip the code then.
identify_build_type expects identify_sourcefile to always set
SOURCE_PACKAGE, set it to "*" in this code path. As it is used as a glob
pattern later, this works good enough for now.
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
'${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.
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.
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.
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.
Michael Prokop
Christoph Berg
Michael Prokop