The Shibboleth project runs a private instance of the Jenkins continuous integration server. Previously, this server provided unauthenticated read-only access to anyone with an interest in the project, however, access has been restricted to project committers due to frequent advisories and updates.
The Jenkins server runs three main classes of job:
In most cases, each project will be associated with one job of each of these three types.
When creating a new Jenkins job, you should follow the guidelines below for each type of job.
Commit rebuild jobs are intended to provide immediate feedback to the developers when a commit is made to the source repository, so that immediate action can be taken if problems have been introduced. Commit rebuild jobs no longer perform much in the way of reporting (other than a go/no-go and test result summary); for detailed reporting, look to the nightly jobs.
java-identity-provider
. H/15 * * * *
H/15
" formulation is Jenkins "hash notation" meaning that the poll should be executed every 15 minutes, but otherwise randomised so that for example all the commit rebuild jobs don't fire at exactly the same time. This helps to even out the load on our shared infrastructure server, which hosts our Jenkins and Subversion servers as well as things like JIRA and Confluence.clean -Prelease install
Note that the commit rebuild jobs take advantage of the Jenkins Maven plugin's ability to compute relationships between jobs and trigger "downstream" jobs when an "upstream" job completes. For example, a commit to the java-parent-v3
project will ultimately cause all of the V3 Jenkins jobs to be run. The dependency graph should be checked from time to time to make sure that jobs aren't being missed out due to dependency issues.
Multi-JDK jobs are intended to provide a more in-depth verification of the current state of a source repository by building and testing in different Java environments. Because these jobs are much more expensive to run, and relatively rarely pick up problems that the corresponding commit rebuild job does not, multi-jdk jobs are run much less frequently.
-multi-jdk
, e.g., java-identity-provider-multi-jdk
.15 20 * * *
clean verify -Prelease
Nightly jobs are run once per day. Their principal functions are:
SNAPSHOT
artifacts and deploy them to our Nexus Maven repository for use by active developers, both within the Shibboleth team and externally. Nightly jobs never deploy release artifacts.Nightly jobs are configured as follows:
-nightly
, e.g., java-identity-provider-nightly
.trigger-nightly-v7,
trigger-nightly-v8
) which determines the time the group is rebuilt. This triggers the building of the parent project's nightly.clean -Prelease -U deploy site
site
goal enables things like the Checkstyle and Cobertura results to be published.target/site | index.html | Site Report
foo-parent/target/site/apidocs
for multi-module project**/target/surefire-reports/testng-results.xml
commits@shibboleth.net
The V7 nightly job group executes in the following order, with indentation indicating branching from the main chain:
trigger-nightly-v7
(at 20:00 Eastern every day)java-parent-project-v7-nightly
ant-extensions-nightly
jetty7-dta-ssl-nightly
jetty9-dta-ssl-nightly
tomcat6-dta-ssl-nightly
java-support-v7-nightly
spring-extensions-v5-nightly
java-metadata-aggregator-v0.9-nightly
java-opensaml-nightly
java-identity-provider-nightly
java-idp-testbed-nightly
The V8 nightly group executes in the following order:
trigger-nightly-v8
(at 20:00 Eastern every day)java-parent-project-v8-nightly
Jenkins is configured to use only one "executor" in our deployment; the default shipped with Jenkins is to use two.
mvn install
goals cannot execute safely in parallel.Jenkins and its plugins are updated fairly regularly, but it's probably only worth paying attention if there's something we need, or a known security issue. Ian intends to do an update sweep every couple of months. Another reason to do an update sweep is that a new plugin to be installed requires a later version of the core of Jenkins than the one we're running.
Always update the core of Jenkins before updating plugins. If you go to the plugin administration page first, you will quite often find that the latest updates to modules require the latest version of the Jenkins core, and disclaim behaviour on an older version.
To update the core of Jenkins:
Manage Jenkins
| Prepare for shutdown
. This will tell Jenkins to stop executing new jobs, so that it will become safe to shut it down once any running at present have completed. You will start seeing a red banner saying "Jenkins is going to shut down" on every page.sudo yum update jenkins
To stop or start Jenkins :
sudo systemctl stop jenkins
sudo systemctl start jenkins
Once this has restarted, check that things are basically functional before proceeding to update the plugins.
Now update the plugins:
Manage Jenkins
| Prepare for shutdown
. This will tell Jenkins to stop executing new jobs, so that it will become safe to shut it down once any running at present have completed. You will start seeing a red banner saying "Jenkins is going to shut down" on every page.Manage Jenkins
| Manage Plugins