KB at your finger tips
This is one stop global knowledge base where you can learn about all the products, solutions and support features.
DevOps-Jenkins
About Jenkins
About Jenkins
The Manage Jenkins >> About Jenkins page shows the current release of Jenkins on your system plus information about licenses for all components. The top of the display shows the release and version of Jenkins that is running.
The following information about your Jenkins cluster is also provided:
-
List of all third-party libraries used for this release of Jenkins, with links to licensing details about each library.
-
List of static resources that are installed.
-
List of installed plugins, each of which includes a link to the page that shows all third-party dependencies for each plugin with a link to licensing details about each library.
This video shares different methods to check the version of Jenkins being used.
Was this page helpful?
Please submit your feedback about this page through this quick form.
Alternatively, if you don't wish to complete the quick form, you can simply indicate if you found this page helpful?
See existing feedback here.
Built-In Node Name and Label Migration
Built-In Node Name and Label Migration
As part of the terminology cleanup effort, the built-in node was renamed from "master node" to "built-in node" in Jenkins 2.307 and in Jenkins 2.319.1.
This is not just a change affecting the UI and documentation:
The node name affects the implicitly assigned label of the node (and consequently the
NODE_LABELS
environment variable), as well as the
NODE_NAME
environment variable.
The
NODE_NAME
environment variable in Pipelines is set by the Pipeline: Nodes and Processes plugin.
In plugin version 2.39 and earlier, this value is always
master
. Update to version 2.40 or newer to get consistent behavior between job types.
|
Affected Features
Jenkins features using node labels are therefore potentially impacted by any such changes. These features include:
-
Label assignments of various project types, both on the top level (e.g. Freestyle jobs) and within jobs (e.g.
nodestatements in Scripted Pipeline,labelparameters toagentsections in Declarative Pipeline, or Matrix Project axes). -
Label assignments of features like custom tool auto-installers, typically used to distinguish OS platforms.
-
Any custom build scripts whose behavior is different based on the
NODE_NAMEorNODE_LABELSenvironment variables (or theirenvglobal variable equivalent in Pipeline). -
Any similar features in plugins.
Migration
Due to the potential impact to build behavior, instances upgrading Jenkins to version 2.307 or newer do not automatically get these behavior changes applied. Instead, an administrative monitor informs administrators about this change and allows them to apply it.
Before applying the built-in node name and label migration, administrators are advised to review their configuration and build scripts to assess the impact to their instance and jobs.
Most problems with label assignments can likely be worked around by manually assigning the label
master
to the built-in node and then migrating affected configuration incrementally to not need this workaround.
Plugin Compatibility
Known Incompatible Plugins
-
Pipeline: Nodes and Processes always sets the
NODE_NAMEtomasterin Pipelines before version 2.40. -
Node and Label Parameter plugin displays the controller node as
masterin releases before version 1.10.0.
Use this Jira query to find compatibility issues tracked in the Jenkins Jira.
Use this GitHub query to find compatibility issues tracked on GitHub.
Reporting Incompatible Plugins
Please report problems in the respective plugin’s issue tracker.
If the affected plugin uses the Jenkins Jira to track issues, please add the label
built-in-node-migration-regression
.
If the affected plugin tracks issues on GitHub, please make sure to mention the Jenkins pull request that implemented the change in your issue.
Configuration as Code
Configuration as Code
The Jenkins Configuration as Code (JCasC) feature defines Jenkins configuration parameters in a human-readable YAML file that can be stored as source code. This essentially captures the configuration parameters and values that are used when configuring Jenkins from the web UI. The configuration can then be modified by editing this file and then applying it.
|
Traditionally, experienced Jenkins administrators
created Apache Groovy
|
JCasC provides the convenience and flexibility of configuring controllers without using the UI. It does not require more understanding of the configuration parameters than is required to configure Jenkins through the UI and it provides some checks on the values that are provided.
The JCasC configuration file can be checked into an SCM, which enables you to determine who made what modifications to the configuration and to roll back to a previous configuration if necessary.
The Configuration as Code plugin must be installed on the Jenkins controller that you will use to build out your JCasC configuration. If you do not see the Configuration as Code tile in the System Configuration section of the Manage Jenkins page on your dashboard, you need to install the plugin.
Viewing the JCasC file
When the Configuration as Code plugin is installed, you will see Configuration as Code in the System Configuration section of the Manage Jenkins page on your dashboard. Click on this link, then click on View Configuration to view the YAML file.
This file is an export of the current configuration on this controller. In most cases, it is ready to use without modification although you usually want to customize it before deploying it. You may want to push the unmodified version to SCM so you have it as part of your history.
|
The Configuration as Code UI page shows the full pathname of the YAML file being used and gives a box where you can specify a different file to use. See the information below about how to modify the location used for JCasC YAML files. |
The default JCasC YAML file has four sections:
-
jenkinssection defines the root Jenkins object, with configurations that can be set with the Manage Jenkins >> Configure System and Manage Jenkins >> Configure Nodes and Clouds screens. -
toolsection defines build tools that can be set on the Manage Jenkins >> Global Tool Configuration screen. -
unclassifiedsection defines all other configurations, including configuration for installed plugins. -
credentialssection defines credentials that can be set on the Manage Jenkins >> Manage Credentials screen. You may want to delete this section from your YAML file; this is discussed in How to Install Jenkins on CentOS 7 Using Ansible and JCasC.
YAML file syntax
JCasC defines the controller configuration in a YAML file. YAML is a popular serialization language for configuration information, with a syntax that is straight-forward and easy to read but precise.
Some key points about YAML syntax:
-
YAML files are case sensitive.
-
Indentation is very significant and specific.
-
Each item is a key/value pair.
-
The key is followed by a colon (
:) and a space. -
YAML converts certain strings into other types unless they are in quotes.
-
Values such as
true,false,Yes, andNoare converted to Boolean values. -
Values such as
2and3.0are converted to floating point values.
-
-
-
A value can be a list:
-
Each list item is on a separate line starting with a dash (
-). -
Each list item in the file must start at the same indentation.
-
Use spaces, never tabs, for indentation.
-
-
Never leave a blank line in a YAML file — things will break!
-
See the YAML Reference Card for more details about YAML file syntax.
Checking the YAML files into SCM
To get the maximum benefit of JCasC, the YAML files should be stored in SCM. This gives you a history that you can use to trace changes that are made and allow you to easily roll back to an earlier version of the file if necessary.
JCasC does not require that the file be stored in SCM and so does not enforce any rules about how you do this. The most common practice is to create one SCM repository in which you store all of your JCasC files.
If you are storing your JCasC YAML files in SCM, you should commit the first default file that is generated, before you make any modifications to the file.
Modifying the JCasC file
To modify the JCasC YAML file, use the text editor of your choice to edit the file that is listed on the Manage Jenkins >> Configuration as Code UI page. By default, this is $JENKINS_HOME/jenkins.yaml .
For a simple exercise to work through the process, you can modify the value of the "System Message" that is displayed on the Jenkins dashboard.
-
Open the JCasC YAML file with the text editor of your choice.
-
Find the
systemMessageline near the top of the file:jenkins: systemMessage: "Jenkins configured automatically by Jenkins Configuration as Code plugin\n\n" -
Modify the text between the quotation marks to contain your new text
-
Write/save the file
-
Click the Reload existing configuration button to apply the changes
-
View the modified "System Message" on your dashboard
|
It is not necessary to restart Jenkins to apply the JCasC changes, although you should try to restart Jenkins with the modifications before you check the modified YAML file into SCM, especially when making more substantive configuration changes. |
When you have made and tested your desired changes, push the modified JCasC YAML file to your SCM.
Configuring a plugin with JCasC
To configure a plugin with JCasC:
-
Use the UI of the current system to install and configure the plugin
-
Click Apply >> Save to save the configuration
-
Use Manage Jenkins >> Configuration as Code >> View Configuration to view the JCasC file with the plugin configured
-
Click on Download Configuration to save the modified configuration file locally
-
Edit the JCasC YAML file to modify the configuration, if necessary
-
Save the file
-
Click Reload existing configuration to load the local changes onto the Jenkins server
-
Verify the changes on the UI
-
When you have thoroughly tested the plugin configuration, push the modified YAML file to your SCM
See the Configure Plugins with JCasC blog for detailed instructions and an embedded video demonstration of this process.
YAML file location
By default, the YAML file for the CasC configuration
is located in
$JENKINS_HOME/jenkins.yaml
.
The location and name of the file being used is displayed
on the
Configuration as Code
UI page.
You can specify a different file to view by typing the full pathname
into the
Path or URL
field.
You can specify a different location or a different file name for the creation of the JCasC YAML file by doing either of the following:
-
Populate the
CASC_JENKINS_CONFIGenvironment variable to point to a comma-separated list that defines where configuration files are located. -
Use the
casc.jenkins.configJava property to control the file name and location. This is useful when installing Jenkins via a package management tool. Most package management systems support configuration files that are retained across upgrades. It is best to not modify a file installed by a package manager because it could be overwritten by an update.On Linux systems, you can run
systemctl edit jenkinsand add the following:[Service] Environment="JAVA_OPTS=-Dcasc.jenkins.config=/jenkins/casc_configs"
The file location and name can be specified as any of the following:
-
Path to a folder containing a set of config files such as
/var/jenkins_home/casc_configs. -
A full path to a single file such as
/var/jenkins_home/casc_configs/jenkins.yaml. -
A URL pointing to a file served on the web such as
https://acme.org/jenkins.yaml.
The value of the
CASC_JENKINS_CONFIG
variable is unpacked
according to the following rules:
-
If an element of
CASC_JENKINS_CONFIGpoints to a folder, the plugin recursively traverses the folder to find file(s) with the .yml, .yaml, .YAML, or .YML suffix. -
It excludes hidden files or files that contain a hidden folder (such as/
jenkins/casc_configs/.dir1/config.yaml) in any part of the full path. -
It follows symbolic links for both files and directories.
-
The order of traversal does not matter to the final outcome because all configuration files that are discovered MUST be supplementary. If a file attempts to overwrite configuration values from another file, it creates a conflict and raises a
ConfiguratorException.
CasC configuration and UI modifications
Configuration for a Jenkins controller should be implemented either with CasC or with the UI, but not by both. The system allows administrators to modify configuration options on the UI even when they were configured by CasC, but these modifications are overwritten the next time the controller restarts.
You can install the Extended Read Permission Plugin, which allows you to grant read-only access to configuration parameters to users. See JEP-224: Readonly system configuration for more details.
A small group of administrators may have write access to the UI configuration fields. They should understand that JCasC will overwrite changes they make on the UI.
For more information
General information
-
Look Ma! No Hands! — Manage Jenkins Configuration as Code is a video of the 2018 DevOps World presentation that introduced the JCasC feature.
-
Configure Plugins with JCasC is a blog post with video that demonstrates how to configure a plugin with JCasC.
-
How to Install Jenkins on CentOS 7 Using Ansible and JCasC is a video presentation with details about using JCasc.
Implementation details
Much of the detailed JCasC documentation is provided in the Github repository.
-
Implementation details
-
The demos directory contains sample *.yaml files for configuring specific Jenkins components and plugins, with a README file in each directory that describes the configurations for that component.
-
How to create the initial "seed" job with Job DSL
-
Usage scenarios
-
Triggering Configuration Reload
-
Exporting configurations
-
Information for plugin developers and maintainers
-
Developer documentation for JCasC
-
JCasC Requirements - guide for plugin maintainers
Was this page helpful?
Please submit your feedback about this page through this quick form.
Alternatively, if you don't wish to complete the quick form, you can simply indicate if you found this page helpful?
See existing feedback here.
Change System Time Zone
Change System Time Zone
- User Defined Time Zone
- System Time Zone properties
The system time zone configuration is the default time zone displayed by Jenkins. The "Manage Jenkins" ⇒ "System Information" page shows the value of the system properties that define the time zone for the Jenkins controller.
Refer to the following video for tips on changing the time zone
User Defined Time Zone
A user defined time zone for the account can be set from the configure option in the user settings.
System Time Zone properties
If you cannot change the time zone of your server, you can force jelly to use a given time zone for formatting time stamps.
You need to start your Jenkins with the following java system property:
java -Dorg.apache.commons.jelly.tags.fmt.timeZone=TZ ...where TZ is a java.util.TimeZone ID ("Europe/Paris" for example).
Note that
user.timezone=Europe/Paris
will work as well, but it can interfere with other contexts.
If running Jenkins via a Linux package, this can be accomplished
by running
systemctl edit jenkins
and adding the following:
[Service]
Environment="JAVA_OPTS=-Dorg.apache.commons.jelly.tags.fmt.timeZone=America/New_York"or, if that doesn’t work:
[Service]
Environment="JAVA_OPTS=-Duser.timezone=America/New_York"On FreeBSD, the file to edit is /etc/rc.conf, and the option to use is:
jenkins_java_opts="-Dorg.apache.commons.jelly.tags.fmt.timeZone=America/Denver"
On windows, edit
%INSTALL_PATH%/jenkins/jenkins.xml
. Put
-Dargs
before
-jar
:
<arguments>-Duser.timezone="Europe/Minsk" -jar "%BASE%\jenkins.war"</arguments>You can also set it from the Jenkins Script Console on a live system without the need for a restart. This can also be included in a Post-initialization script to make it permanent.
System.setProperty('org.apache.commons.jelly.tags.fmt.timeZone', 'America/New_York')Was this page helpful?
Please submit your feedback about this page through this quick form.
Alternatively, if you don't wish to complete the quick form, you can simply indicate if you found this page helpful?
See existing feedback here.
Jenkins CLI
Jenkins CLI
-
Using the CLI over SSH
- Authentication
- Common Commands
-
Using the CLI client
- Comparing SSH and CLI client
- Downloading the client
- Using the client
- Client connection modes
- Common Problems with the CLI client
Jenkins has a built-in command line interface that allows users and administrators to access Jenkins from a script or shell environment. This can be convenient for scripting of routine tasks, bulk updates, troubleshooting, and more.
The command line interface can be accessed over SSH or with the Jenkins CLI
client, a
.jar
file distributed with Jenkins.
|
This document assumes Jenkins 2.54 or newer. Older versions of the CLI client are considered insecure and should not be used. WebSocket support is available when using both server and client 2.217 or newer. |
Using the CLI over SSH
In a new Jenkins installation, the SSH service is disabled by default. Administrators may choose to set a specific port or ask Jenkins to pick a random port in the Configure Global Security page. In order to determine the randomly assigned SSH port, inspect the headers returned on a Jenkins URL, for example:
% curl -Lv https://JENKINS_URL/login 2>&1 | grep -i 'x-ssh-endpoint'
< X-SSH-Endpoint: localhost:53801
%
With the random SSH port (
53801
in this example), and Authentication
configured, any modern SSH client may securely execute CLI commands.
Authentication
Whichever user used for authentication with the Jenkins controller must have the
Overall/Read
permission in order to
access
the CLI. The user may require
additional permissions depending on the commands executed.
Authentication in SSH mode relies on
SSH-based public/private key authentication. In order to add an SSH public key
for the appropriate user, navigate to
JENKINS_URL/me/configure
and paste an SSH public key
into the appropriate text area.
Common Commands
Jenkins has a number of built-in CLI commands which can be found in every
Jenkins environment, such as
build
or
list-jobs
. Plugins may also provide
CLI commands; in order to determine the full list of commands available
in a given Jenkins environment, execute the CLI
help
command:
% ssh -l kohsuke -p 53801 localhost helpThe following list of commands is not comprehensive, but it is a useful starting point for Jenkins CLI usage.
build
One of the most common and useful CLI commands is
build
, which allows the
user to trigger any job or Pipeline for which they have permission.
The most basic invocation will simply trigger the job or Pipeline and exit, but with the additional options a user may also pass parameters, poll SCM, or even follow the console output of the triggered build or Pipeline run.
% ssh -l kohsuke -p 53801 localhost help build
java -jar jenkins-cli.jar build JOB [-c] [-f] [-p] [-r N] [-s] [-v] [-w]
Starts a build, and optionally waits for a completion. Aside from general
scripting use, this command can be used to invoke another job from within a
build of one job. With the -s option, this command changes the exit code based
on the outcome of the build (exit code 0 indicates a success) and interrupting
the command will interrupt the job. With the -f option, this command changes
the exit code based on the outcome of the build (exit code 0 indicates a
success) however, unlike -s, interrupting the command will not interrupt the
job (exit code 125 indicates the command was interrupted). With the -c option,
a build will only run if there has been an SCM change.
JOB : Name of the job to build
-c : Check for SCM changes before starting the build, and if there's no
change, exit without doing a build
-f : Follow the build progress. Like -s only interrupts are not passed
through to the build.
-p : Specify the build parameters in the key=value format.
-s : Wait until the completion/abortion of the command. Interrupts are passed
through to the build.
-v : Prints out the console output of the build. Use with -s
-w : Wait until the start of the command
% ssh -l kohsuke -p 53801 localhost build build-all-software -f -v
Started build-all-software #1
Started from command line by admin
Building in workspace /tmp/jenkins/workspace/build-all-software
[build-all-software] $ /bin/sh -xe /tmp/hudson1100603797526301795.sh
+ echo hello world
hello world
Finished: SUCCESS
Completed build-all-software #1 : SUCCESS
%console
Similarly useful is the
console
command, which retrieves the console output
for the specified build or Pipeline run. When no build number is provided, the
console
command will output the last completed build’s console output.
% ssh -l kohsuke -p 53801 localhost help console
java -jar jenkins-cli.jar console JOB [BUILD] [-f] [-n N]
Produces the console output of a specific build to stdout, as if you are doing 'cat build.log'
JOB : Name of the job
BUILD : Build number or permalink to point to the build. Defaults to the last
build
-f : If the build is in progress, stay around and append console output as
it comes, like 'tail -f'
-n N : Display the last N lines
% ssh -l kohsuke -p 53801 localhost console build-all-software
Started from command line by kohsuke
Building in workspace /tmp/jenkins/workspace/build-all-software
[build-all-software] $ /bin/sh -xe /tmp/hudson1100603797526301795.sh
+ echo hello world
yes
Finished: SUCCESS
%who-am-i
The
who-am-i
command is helpful for listing the current user’s credentials
and permissions available to the user. This can be useful when debugging the
absence of CLI commands due to the lack of certain permissions.
% ssh -l kohsuke -p 53801 localhost help who-am-i
java -jar jenkins-cli.jar who-am-i
Reports your credential and permissions.
% ssh -l kohsuke -p 53801 localhost who-am-i
Authenticated as: kohsuke
Authorities:
authenticated
%Using the CLI client
While the SSH-based CLI is fast and covers most needs, there may be situations where the CLI client distributed with Jenkins is a better fit. For example, the default transport for the CLI client is HTTP which means no additional ports need to be opened in a firewall for its use.
Comparing SSH and CLI client
Both SSH and jenkins-cli.jar provide access to a set of commands that lets you interact with Jenkins from a command line, but they have a few differences:
-
Jenkins SSH does not require any custom jar file on the client side, making it easier to access Jenkins from a variety of sources
-
SSH client was build to be a generic tool to serve several purposes. It doesn’t offer an easy way to do basic things that are common and specific to Jenkins environments. Using the
jenkins-cli.jarinstead of the ssh client may increase productivity and improve the development experience
Downloading the client
The CLI client can be downloaded directly from a Jenkins controller at the URL
/jnlpJars/jenkins-cli.jar
, in effect
JENKINS_URL/jnlpJars/jenkins-cli.jar
While a CLI
.jar
can be used against different versions of Jenkins, should
any compatibility issues arise during use, please re-download the latest
.jar
file from the Jenkins controller.
Using the client
The general syntax for invoking the client is as follows:
java -jar jenkins-cli.jar [-s JENKINS_URL] [global options...] command [command options...] [arguments...]
The
JENKINS_URL
can be specified via the environment variable
$JENKINS_URL
.
Summaries of other general options can be displayed by running the client with no arguments at all.
Client connection modes
There are three basic modes in which the client may be used, selectable by global option:
-http
,
-webSocket
, and
-ssh
.
HTTP connection mode
This is the default mode, though you may pass the
-http
option explicitly for clarity.
Authentication is preferably with an
-auth
option, which takes a
username:apitoken
argument.
Get your API token from
/me/configure
:
java -jar jenkins-cli.jar [-s JENKINS_URL] -auth kohsuke:abc1234ffe4a command ...(Actual passwords are also accepted, but this is discouraged.)
You can also precede the argument with
@
to load the same content from a file:
java -jar jenkins-cli.jar [-s JENKINS_URL] -auth @/home/kohsuke/.jenkins-cli command ...|
For security reasons the use of a file to load the authentication credentials is the recommended authentication way. |
An alternative authentication method is to configure environment variables in a similar way as the
$JENKINS_URL
is used.
The
username
can be specified via the environment variable
$JENKINS_USER_ID
while the
apitoken
can
be specified via the variable
$JENKINS_API_TOKEN
.
Both variables have to be set all at once.
export JENKINS_USER_ID=kohsuke
export JENKINS_API_TOKEN=abc1234ffe4a
java -jar jenkins-cli.jar [-s JENKINS_URL] command ...
In case these environment variables are configured you could still override the authentication method using different
credentials with the
-auth
option, which takes preference over them.
Generally no special system configuration need be done to enable HTTP-based CLI connections. If you are running Jenkins behind an HTTP(S) reverse proxy, ensure it does not buffer request or response bodies.
|
This mode is known to not work reliably or at all when using certain reverse proxies. Prefer WebSocket mode. |
WebSocket connection mode
In Jenkins 2.217 and above, the
-webSocket
mode may be used as an alternative to
-http
.
The advantage is that a more standard transport is used,
avoiding problems with many reverse proxies or the need for special proxy configuration.
SSH connection mode
Authentication is via SSH keypair. You must select the Jenkins user ID as well:
java -jar jenkins-cli.jar [-s JENKINS_URL] -ssh -user kohsuke command ...
In this mode, the client acts essentially like a native
ssh
command.
By default the client will try to connect to an SSH port on the same host as is used in the
JENKINS_URL
.
If Jenkins is behind an HTTP reverse proxy, this will not generally work,
so run Jenkins with the system property
-Dorg.jenkinsci.main.modules.sshd.SSHD.hostName=ACTUALHOST
to define a hostname or IP address for the SSH endpoint.
Common Problems with the CLI client
There are a number of common problems that may be experienced when running the CLI client.
Server key did not validate
You may get the error below and find a log entry just below that concerning
mismatched keys
:
org.apache.sshd.common.SshException: Server key did not validate
at org.apache.sshd.client.session.AbstractClientSession.checkKeys(AbstractClientSession.java:523)
at org.apache.sshd.common.session.helpers.AbstractSession.handleKexMessage(AbstractSession.java:616)
...This means your SSH configuration does not recognize the public key presented by the server. It’s often the case when you run Jenkins in dev mode and multiple instances of the application are run under the same SSH port over time.
In a development context, access your
~/.ssh/known_hosts
(or in
C:/Users/<your_name>/.ssh/known_hosts
for Windows)
and remove the line corresponding to your current SSH port (e.g.
[localhost]:3485
).
In a production context, check with the Jenkins administrator if the public key of the server changed recently.
If so, ask the administrator to do the the steps described above.
UsernameNotFoundException
If your client displays a stacktrace that looks like:
org.acegisecurity.userdetails.UsernameNotFoundException: <name_you_used>
...This means your SSH keys were recognized and validated against the stored users but the username is not valid for the security realm your application is using at the moment. This could occur when you were using the Jenkins database initially, configured your users, and then switched to another security realm (like LDAP, etc.) where the defined users do not exist yet.
To solve the problem, ensure your users exist in your configured security realm.
Troubleshooting logs
To get more information about the authentication process:
-
Go into Manage Jenkins > System Log > Add new log recorder .
-
Enter any name you want and click on Ok .
-
Click on Add
-
Type
org.jenkinsci.main.modules.sshd.PublicKeyAuthenticatorImpl(or typePublicKeyAuthand then select the full name) -
Set the level to ALL .
-
Repeat the previous three steps for
hudson.model.User -
Click on Save
When you try to authenticate, you can then refresh the page and see what happen internally.
Was this page helpful?
Please submit your feedback about this page through this quick form.
Alternatively, if you don't wish to complete the quick form, you can simply indicate if you found this page helpful?
See existing feedback here.
Groovy Hook Scripts
Groovy Hook Scripts
|
This section is a work in progress. Want to help? Check out the jenkinsci-docs mailing list. For other ways to contribute to the Jenkins project, see this page about participating and contributing. |
- Post initialization script (init hook)
- Boot failure hook
In several places inside Jenkins, a series of "hook scripts" get executed to allow some actions to take place in reaction to some key events.
These scripts are written in Groovy, and get executed inside the same JVM as Jenkins, allowing full access to the domain model of Jenkins. For given hook HOOK , the following locations are searched:
-
WEB-INF/HOOK.groovyinjenkins.war -
WEB-INF/HOOK.groovy.d/*.groovyin the lexical order injenkins.war -
$JENKINS_HOME/HOOK.groovy -
$JENKINS_HOME/HOOK.groovy.d/*.groovyin the lexical order
HOOK.groovy.d
is suitable to avoid conflicts â multiple entities can
insert stuff into the hook without worrying about overwriting each
other’s code.
The following events use this mechanism by replacing
HOOK
in
HOOK.groovy.d
or
HOOK.groovy
by one of the below mentioned types:
-
init : Post-initialization script
-
boot-failure : Boot failure hook
Post initialization script (init hook)
You can create a Groovy script file
$JENKINS_HOME/init.groovy
, or
any
.groovy
file in the directory
$JENKINS_HOME/init.groovy.d/
,
to run some additional things right after Jenkins starts up.
The groovy scripts are executed at the end of Jenkins initialization.
This script can access classes in Jenkins and all the plugins.
So for example, you can write something like:
import jenkins.model.Jenkins;
// start in the state that doesn't do any build.
Jenkins.instance.doQuietDown();Output is logged to the Jenkins log file. For Debian based users, this is /var/log/jenkins/jenkins.log
Boot failure hook
When Jenkins encounters a fatal problem during boot, it’ll invoke "boot-failure" hook script to allow automatic corrective actions to be taken (such as notifying somebody, raising alerts, restarting, and so on.)
These scripts get the cause of the problem as the "exception" variable when run.
Was this page helpful?
Please submit your feedback about this page through this quick form.
Alternatively, if you don't wish to complete the quick form, you can simply indicate if you found this page helpful?
See existing feedback here.