Jenkins/Java with OpenJDK might complain about:
| "Caused by: java.lang.Error: Probable fatal error:No fonts found."
and e.g. the "Test Result Trend" graphics are missing then.
Might also require:
JAVA_ARGS="-Djava.awt.headless=true"
inside /etc/default/jenkins. The latest Jenkins packages
already include this, but it's missing in the LTS releases
currently, jftr.
reprepro should be present on every system to avoid failures with
package inclusion in repository. Depending on reprepro in the
main jenkins-debian-glue package avoids that problem while still
supporting setups where cowbuilder etc aren't necessary on
repository-only systems.
Closes: #76
We want to have jenkins-debian-glue-repoenv by default on
automatically installed machines and users typically want it,
though they don't strictly need it, so add it to Recommends.
Related to commit c73c341f ("puppet: install git-client plugin
explicitely in version 1.1.2"), instead of pinning the git-client plugin
to a specific version also install the latest versions of the ssh-agent
and credentials plugins and pin the credentials plugin so it doesn't
get restored/downgraded by Jenkins service itself.
Thanks stephenconnolly for the hint regarding the pinning trick.
See https://issues.jenkins-ci.org/browse/JENKINS-19927
git-client plugin version 1.3.0 depends on ssh-agent which depends on
credentials plugin version 1.6 or newer. Otherwise it's failing with:
| SEVERE: Failed Loading plugin git-client
| java.io.IOException: Dependency ssh-agent (1.3) doesn't exist
Jenkins LTS 1.509.3 provides Credentials plugin version 1.3.1.
Jenkins 1.534 provides Credentials plugin version 1.4.
Recent versions of the git-client plugin (at least 1.3.0) depend on the
ssh-agent plugin which itself requires version >=1.6 of the Credentials
plugin though, otherwise it's failing with:
| FATAL: com/cloudbees/plugins/credentials/common/StandardCredentials
| java.lang.NoClassDefFoundError: com/cloudbees/plugins/credentials/common/StandardCredentials
| at org.jenkinsci.plugins.gitclient.Git$1.invoke(Git.java:62)
| [...]
Manually updating the credentials plugin in an automated fashion doesn't
seem to be possible (when placing
http://updates.jenkins-ci.org/latest/credentials.hpi inside the plugin
directory then on Jenkins restart the built-in credentials plugin seems
to always get restored to its old/built-in version).
So unless there's a way to update a built-in plugin besides using the
web interface with its plugin manager we've to install a git-client
plugin version that's known to work without further, unresolvable plugin
dependencies.
Reported upstream as https://issues.jenkins-ci.org/browse/JENKINS-19927
For some reason current versions of Jenkins with TAP plugin fail to
retrieve the artifacts and the jenkins-debian-glue-piuparts job fails
with:
| Unable to find a build for artifact copy from: jenkins-debian-glue-binaries
| Build step 'Copy artifacts from another project' marked build as failure
| TAP Reports Processing: START
| Looking for TAP results report in workspace using pattern: piuparts.tap
| Did not find any matching files.
The 'Parameter filters' option from the 'Copy artifacts from another
project' setting gets set to "architecture=$architecture" when using
the 'projectName' tag. By using
'jenkins-debian-glue-binaries/architecture=$architecture' inside the
'project' tag the 'Parameter filters' option is empty again and does
what it is supposed to do.
Jenkins depends on a working Java runtime package but has just
'java2-runtime' in its depends (which is a virtual package),
this results in a broken default installation. So make sure
a Java runtime package is picked up by explicitely installing
default-jre-headless.
Thanks: Cyril Brulebois for the bug report
Junit is available out-of-the-box in Jenkins and our configuration
actually uses that, so there's no point in installing the xunit
plugin by default.
Verified on fresh Ubuntu 12.04 EC2 system.
Thanks: Sylvestre Ledru <sylvestre.ledru@scilab-enterprises.com>
for bringing this up in https://github.com/mika/jenkins-debian-glue.org/pull/4
Debian's AMI[1] doesn't provide anything
inside 'facter ec2_public_ipv4', so let's try
the manual approach then before really falling
back to 'ip addr ...' hackery to avoid retrieval
of internal IP on Debian's AMI/EC2 system.
[1] http://wiki.debian.org/Cloud/AmazonEC2Image
Michael Prokop
Michael Prokop
Michael Prokop