12.3. Jenkins agent
OpenShift Container Platform provides three images that are suitable for use as Jenkins agents: the Base
, Maven
, and Node.js
images.
The first is a base image for Jenkins agents:
-
It pulls in both the required tools, headless Java, the Jenkins JNLP client, and the useful ones including
git
,tar
,zip
, andnss
among others. - It establishes the JNLP agent as the entrypoint.
-
It includes the
oc
client tooling for invoking command line operations from within Jenkins jobs. -
It provides Dockerfiles for both Red Hat Enterprise Linux (RHEL) and
localdev
images.
Two more images that extend the base image are also provided:
- Maven v3.5 image
- Node.js v10 image and Node.js v12 image
The Maven and Node.js Jenkins agent images provide Dockerfiles for the Universal Base Image (UBI) that you can reference when building new agent images. Also note the contrib
and contrib/bin
subdirectories. They allow for the insertion of configuration files and executable scripts for your image.
Use and extend an appropriate agent image version for the your of OpenShift Container Platform. If the oc
client version that is embedded in the agent image is not compatible with the OpenShift Container Platform version, unexpected behavior can result.
12.3.1. Jenkins agent images
The OpenShift Container Platform Jenkins agent images are available on Quay.io or registry.redhat.io.
Jenkins images are available through the Red Hat Registry:
$ docker pull registry.redhat.io/openshift4/ose-jenkins:<v4.5.0>
$ docker pull registry.redhat.io/openshift4/jenkins-agent-nodejs-10-rhel7:<v4.5.0>
$ docker pull registry.redhat.io/openshift4/jenkins-agent-nodejs-12-rhel7:<v4.5.0>
$ docker pull registry.redhat.io/openshift4/ose-jenkins-agent-maven:<v4.5.0>
$ docker pull registry.redhat.io/openshift4/ose-jenkins-agent-base:<v4.5.0>
To use these images, you can either access them directly from Quay.io or registry.redhat.io` or push them into your OpenShift Container Platform container image registry.
12.3.2. Jenkins agent environment variables
Each Jenkins agent container can be configured with the following environment variables.
Variable | Definition | Example values and settings |
---|---|---|
|
These values control the maximum heap size of the Jenkins JVM. If By default, the maximum heap size of the Jenkins JVM is set to 50% of the container memory limit with no cap. |
|
|
These values control the initial heap size of the Jenkins JVM. If By default, the JVM sets the initial heap size. |
|
| If set, specifies an integer number of cores used for sizing numbers of internal JVM threads. |
Example setting: |
| Specifies options to apply to all JVMs running in this container. It is not recommended to override this value. |
Default: |
| Specifies Jenkins JVM garbage collection parameters. It is not recommended to override this value. |
Default: |
| Specifies additional options for the Jenkins JVM. These options are appended to all other options, including the Java options above, and can be used to override any of them, if necessary. Separate each additional option with a space and if any option contains space characters, escape them with a backslash. |
Example settings: |
12.3.3. Jenkins agent memory requirements
A JVM is used in all Jenkins agents to host the Jenkins JNLP agent as well as to run any Java applications such as javac
, Maven, or Gradle.
By default, the Jenkins JNLP agent JVM uses 50% of the container memory limit for its heap. This value can be modified by the CONTAINER_HEAP_PERCENT
environment variable. It can also be capped at an upper limit or overridden entirely.
By default, any other processes run in the Jenkins agent container, such as shell scripts or oc
commands run from pipelines, cannot use more than the remaining 50% memory limit without provoking an OOM kill.
By default, each further JVM process that runs in a Jenkins agent container uses up to 25% of the container memory limit for its heap. It might be necessary to tune this limit for many build workloads.
12.3.4. Jenkins agent Gradle builds
Hosting Gradle builds in the Jenkins agent on OpenShift Container Platform presents additional complications because in addition to the Jenkins JNLP agent and Gradle JVMs, Gradle spawns a third JVM to run tests if they are specified.
The following settings are suggested as a starting point for running Gradle builds in a memory constrained Jenkins agent on OpenShift Container Platform. You can modify these settings as required.
-
Ensure the long-lived Gradle daemon is disabled by adding
org.gradle.daemon=false
to thegradle.properties
file. -
Disable parallel build execution by ensuring
org.gradle.parallel=true
is not set in thegradle.properties
file and that--parallel
is not set as a command line argument. -
To prevent Java compilations running out-of-process, set
java { options.fork = false }
in thebuild.gradle
file. -
Disable multiple additional test processes by ensuring
test { maxParallelForks = 1 }
is set in thebuild.gradle
file. -
Override the Gradle JVM memory parameters by the
GRADLE_OPTS
,JAVA_OPTS
orJAVA_TOOL_OPTIONS
environment variables. -
Set the maximum heap size and JVM arguments for any Gradle test JVM by defining the
maxHeapSize
andjvmArgs
settings inbuild.gradle
, or through the-Dorg.gradle.jvmargs
command line argument.
12.3.5. Jenkins agent pod retention
Jenkins agent pods, are deleted by default after the build completes or is stopped. This behavior can be changed by the Kubernetes plug-in pod retention setting. Pod retention can be set for all Jenkins builds, with overrides for each pod template. The following behaviors are supported:
-
Always
keeps the build pod regardless of build result. -
Default
uses the plug-in value, which is the pod template only. -
Never
always deletes the pod. -
On Failure
keeps the pod if it fails during the build.
You can override pod retention in the pipeline Jenkinsfile:
podTemplate(label: "mypod",
cloud: "openshift",
inheritFrom: "maven",
podRetention: onFailure(), 1
containers: [
...
]) {
node("mypod") {
...
}
}
- 1
- Allowed values for
podRetention
arenever()
,onFailure()
,always()
, anddefault()
.
Pods that are kept might continue to run and count against resource quotas.