Welcome to Knowledge Base!

KB at your finger tips

This is one stop global knowledge base where you can learn about all the products, solutions and support features.

Categories
All

DevOps-Jenkins

Linux Support Policy

Linux Support Policy

This page documents the Linux support policy for the Jenkins controller and agents.

Scope

Individual Jenkins plugins may set additional requirements for Linux versions on controllers and/or agents. This page does not document such requirements. Please refer to plugin documentation for additional requirements.

Why?

Theoretically, Jenkins can run everywhere where you can run a supported Java version, but there are some limitations in practice. Jenkins core and some plugins include native code or depend on Linux API and subsystems and hence they rely on specific Linux versions. Jenkins platform specific installation packages rely on specific Linux versions.

Support levels

We define multiple support levels for Linux platforms.

Support level Description Platforms

Level 1 - Supported

We run automated package manager installation testing for these platforms and we intend to fix the reported issues in a timely manner. We recommend either package manager based installations or container based installations for Linux. Installations may also use jenkins.war without a package manager, though our automated testing focuses on package manager and container installations.

  • 64-bit (amd64) Linux versions that use the Debian packaging format as tested on ci.jenkins.io

  • 64-bit (amd64) Linux versions that use the Red Hat rpm packaging format as tested on ci.jenkins.io

  • 64-bit (amd64) Linux versions that use the OpenSUSE rpm packaging format as tested on ci.jenkins.io

  • 64-bit (arm64, s390x) Linux versions that use the Debian packaging format as tested on ci.jenkins.io

  • 64-bit (arm64, s390x) Linux versions that use the rpm packaging format as tested on ci.jenkins.io

  • Linux container images (amd64, arm64, s390x) as published for the controller and various agents

Level 2 - Patches considered

Support may have limitations and extra requirements. We do not test compatibility, and we may drop support at any time. We consider patches that do not put level 1 support at risk and do not create maintenance overhead.

  • 32-bit (x86, arm) Linux versions

  • RISC-V and other architectures not included in level 1 support

  • Preview releases

Level 3 - Unsupported

These versions are known to be incompatible or to have severe limitations. We do not support the listed platforms and we do not accept patches.

  • Linux versions no longer supported by operating system providers

References

  • Debian Long Term Support

  • Red Hat Enterprise Linux Life Cycle

  • SUSE Product Support Lifecycle

  • Ubuntu lifecycle and release cadence

Contributing

You are welcome to propose PR’s that add support for other Linux platforms or to share feedback; we will appreciate your contributions! Linux support in Jenkins is Platform Special Interest Group which has a chat, a mailing list, and regular meetings. You are welcome to join these channels.

Version history

  • March 2022 - First version (Discussion in the mailing list, Governance meeting notes and recording)

Servlet Container Support Policy

Servlet Container Support Policy

This page documents the servlet container support policy for the Jenkins controller.

Why?

Jenkins is typically run as a standalone application in its own process. The Jenkins WAR file bundles Winstone, a Jetty servlet container wrapper, and can be started on any operating system or platform with a version of Java supported by Jenkins. This is the preferred way to deploy Jenkins and is fully supported.

Theoretically, Jenkins can also be run as a servlet in a traditional servlet container like Apache Tomcat or WildFly, but in practice this is largely untested and there are many caveats. In particular, support for WebSocket agents is only implemented for the Jetty servlet container.

Support for traditional servlet containers may be discontinued in the future.

Support levels

We define multiple support levels for servlet containers.

Support level Description Servlet containers

Level 1: Supported

We run automated testing for these servlet containers, and we intend to fix reported issues in a timely manner.

The versions of Winstone and Jetty bundled in the Jenkins WAR file.

Level 2: Patches considered

Support may have limitations and extra requirements. We do not regularly test compatibility, and we may drop support at any time. We consider patches that do not put Level 1 support at risk and do not create maintenance overhead.

  • Tomcat 9, based on Servlet API 4.0 (Jakarta EE 8) with javax.servlet imports.

  • WildFly 26, based on Servlet API 4.0 (Jakarta EE 8) with javax.servlet imports.

  • Other servlet containers that are based on Servlet API 4.0 (Jakarta EE 8) with javax.servlet imports.

Level 3: Unsupported

These versions are known to be incompatible or to have severe limitations. We do not support the listed servlet containers.

  • Jetty 11 or later, based on Servlet API 5.0 (Jakarta EE 9) or later with jakarta.servlet imports.

  • Tomcat 10 or later, based on Servlet API 5.0 (Jakarta EE 9) or later with jakarta.servlet imports.

  • WildFly 27 or later, based on Servlet API 5.0 (Jakarta EE 9) or later with jakarta.servlet imports.

  • Other servlet containers that are based on Servlet API 5.0 (Jakarta EE 9) or later with jakarta.servlet imports.

References

  • Installation instructions

  • Jetty versions

  • Tomcat versions

  • WildFly 27 release announcement

Contributing

You are welcome to propose PRs that add support or documentation for other servlet containers or to share feedback; we will appreciate your contributions! Servlet container support in Jenkins falls under the Platform Special Interest Group which has a chat, a mailing list, and regular meetings. You are welcome to join these channels.

Read article

Upgrading Jenkins Java version from 8 to 11

Upgrading Jenkins Java version from 8 to 11

There are a few details and steps to upgrade the JVM used to run Jenkins, more specifically from Java 8 to Java 11.

If you’re upgrading the JVM used to run Jenkins, and particularly if you’re upgrading from Java 8 to Java 11, there are some details you should know and precautions you should take.

Backup

As with any upgrade, we recommend backing up JENKINS_HOME and testing the upgrade with the backup before performing the upgrade on your production instance.

Upgrading Jenkins

If you need to upgrade Jenkins as well as the JVM, we recommend that you:

  1. Back up JENKINS_HOME

  2. Upgrade Jenkins to the most recent version

    • How you upgrade Jenkins is dependent upon your original Jenkins installation method.

    • We recommend that you use the package manager of your system (such as apt or yum ).

  3. Validate the upgrade to confirm that all plugins and jobs are loaded

  4. Upgrade the required plugins (see Upgrading Plugins)

  5. Make a second backup of JENKINS_HOME after upgrading Jenkins and the required plugins

  6. Stop the Jenkins instance

  7. Upgrade the JVM on which Jenkins is running

    • Use a package manager to install the new JVM.

    • Make sure the default JVM is the newly installed version. If it is not, run systemctl edit jenkins and set either the JAVA_HOME environment variable or the JENKINS_JAVA_CMD environment variable.

Starting with the Jenkins 2.357 weekly release and the Long Term Support release 2.361.1, Java 11 or Java 17 is required.

Upgrading Plugins

It’s important not just to upgrade Jenkins and the JVM, but also to upgrade the plugins which support Java 11. Plugin upgrades assure compatibility with the most recent Jenkins releases.

If you discover a previously unreported issue, please let us know: read how to report an issue for guidance.

Jakarta XML Binding

Some plugins use JAXB libraries provided by the JDK. However, the java.xml.bind and javax.activation modules are no longer included in OpenJDK 11, and plugins might fail if no replacement is offered.

To fix this problem, we’ve bundled those libraries into a new detached plugin: JAXB plugin. When any Jenkins core more recent than 2.163 is running on Java 11, this plugin is automatically installed. However, if you manage your plugins outside Jenkins, for example, if you use plugins.txt in your Docker images, you might need to install the plugin explicitly.

JVM version on agents

All agents must be running on the same JVM version as the controller due to how controllers and agents communicate. If you’re upgrading your Jenkins controller to run on Java 11, you also need to upgrade the JVM on your agents.

You can validate the version of each agent with the Versions Node Monitors plugin. This plugin provides information about the JVM version of each agent on the node management screen of your Jenkins instance. You can also configure this plugin to automatically disconnect any agent with an incorrect JVM version.

Java Web Start

Java Web Start has been removed in Java 11. When a Jenkins controller runs on Java 11, the Java Web Start button will no longer appear in the Web UI. You can’t launch agents for a Java 11 Jenkins server from a *.jnlp file downloaded to a web browser.

There are no plans to replace this functionality. Connect agents to Jenkins on Java 11 with plugins like SSH Build Agents Plugin, with operating system command line calls to java -jar agent.jar , or using containers.

JDK Tool Automatic installer

Oracle JDK 11 licensing prevents the Jenkins community from listing the Oracle JDKs. Because of this licensing restriction, Oracle JDK 11 can’t be automatically installed by Jenkins. This problem is tracked in the issue JENKINS-54305.

As an alternative, we encourage you to use containers based on images that contain all the tooling needed for your builds.

Read article

Browser compatibility

Browser compatibility

This page documents the browser support policy in the Jenkins automation server. It does not apply to the Jenkins website or other services hosted by the Jenkins project.

Support model

Jenkins web browser support falls into one of three classes:

  1. Level 1:  Aim to proactively fix these browsers and provide an equal UX across all.

  2. Level 2:  Accept patches to fix issues and make the best effort to ensure there is at least one way to do any action.

  3. Level 3:  No guarantees. We will accept patches, but only if they are low risk. This is the default unless a browser/version is listed below .

We do not claim any compatibility with or accept bug reports and patches for pre-release (e.g., alpha, beta, or canary) versions of browsers.

Browser compatibility matrix

Browser Level 1 Level 2 Level 3

Google Chrome

Latest regular release/patch

Version N-1, latest patch

Other versions

Mozilla Firefox

Latest regular release/patch; Latest ESR release

Version N-1, latest patch

Other versionsÂ

Microsoft Edge

Latest regular release/patch

Version N-1, latest patch

Other versions

Apple Safari

Latest regular release/patch

Version N-1, latest patch

Other versions

Support for mobile browsers (e.g. iOS Safari) has not yet been determined.

Change history

  • 2022-02-01 - Remove support for Internet Explorer, Add Edge (discussion in the developer mailing list)

  • 2019-11-19 - Policy update (discussion in the developer mailing list)

  • 2014-09-03 - Original policy for Jenkins 1.579 (governance meeting notes)

Read article

Windows Support Policy

Windows Support Policy

This page documents the Windows support policy for the Jenkins server and agents.

Scope

Jenkins plugins, e.g., WMI Windows Agents, may set additional requirements to Windows versions on controllers and/or agents. This page does not document such requirements. Please refer to plugin documentation.

Why?

Theoretically, Jenkins can run everywhere where you can run a supported Java version, but there are some limitations in practice. Jenkins core and some plugins include native code or depend on Windows API and subsystems, and hence they rely on specific Windows platforms and versions. In Windows services, we also use Windows Service Wrapper (WinSW), which requires .NET Framework.

Support levels

We define multiple support levels for Windows platforms.

Support level Description Platforms

Level 1 - Full support

We run automated testing for these platforms, and we intend to fix the reported issues timely.

  • 64-bit (amd-64) Windows Server versions, with the latest GA update pack

  • Windows versions used in the official Docker images

Level 2 - Supported

We do not actively test these platforms, but we intend to keep compatibility. We are happy to accept patches.

  • 64-bit (amd-64) Windows Server versions generally supported by Microsoft

  • 64-bit (amd-64) Windows 10 versions generally supported by Microsoft

Level 3 - Patches considered

Support may have limitations and extra requirements. We do not test compatibility, and we may drop support if there is a need. We will consider patches if they do not put Level 1/2 support at risk and do not create maintenance overhead.

  • 64-bit Windows versions no longer supported by Microsoft

  • x86 and other non-amd64 architectures

  • Non-mainstream versions, e.g., Windows Embedded

  • Preview releases

  • Windows API emulation engines, e.g., Wine or ReactOS

Level 4 - Unsupported

These versions are known to be incompatible or to have severe limitations. We do not support the listed platforms, and we will not accept patches.

  • Windows XP older than SP3

  • Windows Phone

  • Other Windows platforms released before 2008

.NET Requirements

  • Starting from Jenkins 2.238 , .NET Framework 4.0 or above is required for all Windows service installations and built-in Windows service management logic.

  • Before Jenkins 2.238 , .NET Framework 2.0 was supported

  • For platforms that do not support these versions, consider using Native executables provided by the Windows Service Wrapper project.

References

  • Microsoft Lifecycle Policy

  • Microsoft Product Lifecycle Search

Contributing

If you would like to add support for more Windows platforms or to share feedback, we will appreciate your contributions! Windows support in Jenkins is Platform Special Interest Group which has a chat, a mailing list, and regular meetings. You are welcome to join these channels.

Version history

  • Jun 03, 2020 - First version (Discussion in the mailing list, Governance meeting notes)

Read article

Activity View

Activity View

Table of Contents
  • Navigation Bar
    • Activity
    • Branches
    • Pull Requests

The Blue Ocean Activity view shows all activities related to one Pipeline.

Blue Ocean status

Blue Ocean will not receive further functionality updates. Blue Ocean will continue to provide easy-to-use Pipeline visualization, but it will not be enhanced further. It will only receive selective updates for significant security issues or functional defects.

The Activity view includes the standard navigation bar at the top and a local navigation bar below it.

Navigation bars from the Activity view

The local navigation bar includes:

  • Pipeline Name - Selecting this displays the default Activity tab.

  • Favorites Toggle - Selecting the favorite icon ☆ to the right of the Pipeline name, adds a branch to the favorites list shown on the dashboard’s favorites list.

  • Tabs (Activity, Branches Pull Requests) - Selecting one of these navigates to the corresponding information in the Activity view.

Activity

The default tab of the Activity view shows a list of the latest completed or active runs. Each line represents the status of a run, run ID, commit information, and when the run completed.

Default activity tab view of the Activity view

  • Selecting a run will bring up the Pipeline run details to provide Pipeline visualization.

  • Active runs can be aborted from this list by selecting the stop icon, which is represented by a ◾ within a circle.

  • Runs that have been completed can be re-run by selecting the re-run icon ↺.

  • The list can be filtered by branch using the "Branch" drop-down in the list header. Branch filter in Blue Ocean activity view

This view does not allow runs to be edited or marked as favorites. To perform these actions, select the Branches tab.

Branches

The Branches tab shows a list of all branches that have a completed or active run in the current Pipeline. Each line in the list corresponds to a branch in source control, displaying the overall health of the branch based on the status of the most recent run, branch name, commit information, and when the run completed.

Branches tab of Activity view

Selecting a branch brings up the Pipeline run details for the latest completed or active run of that branch.

  1. Pipelines where the latest run has been completed can be run again by selecting the run icon, represented by a in a circle.

    • Active runs can be aborted, and display a stop icon, which is represented by a ◾ within a circle.

  2. Selecting the history icon allows you to view the run history for that branch.

  3. The edit icon, represented by a , opens the Pipeline editor for that branch.

  4. The favorite ☆ icon adds a branch to your favorites list on the dashboard. On the dashboard a branch listed under favorites displays a solid star ★. Deselecting the star removes the branch from the favorites list.

Pull Requests

The Pull Requests tab displays a list of all pull requests for the current Pipeline, that have a completed or active run. Each line in the list corresponds to a pull request in source control, which displays the status of the most recent run, run ID, summary, author, and when the run completed.

Activity Pull Requests view

Blue Ocean displays pull requests and branches separately, but the lists behave similarly. Selecting a pull request in this list will bring up the Pipeline run details for the latest completed or active run of that pull request.

  • Active runs can be aborted from this list by selecting the stop icon, which is represented by a ◾ within a circle.

  • Pull requests whose latest run has been completed can be run again by selecting the run icon, represented by a in a circle.

The pull request list does not display health icons, and pull requests cannot be edited or marked as favorites.

By default, when a pull request is closed, Jenkins removes the Pipeline from Jenkins, and runs for that pull request are no longer accessible from Jenkins. The Pipelines removed in this way will need to be cleaned up in the future. This can be changed by adjusting the configuration of the underlying multi-branch Pipeline job.


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.

Read article