Skip to content

Latest commit

 

History

History
136 lines (91 loc) · 6.57 KB

ci.adoc

File metadata and controls

136 lines (91 loc) · 6.57 KB

Jenkins on Jenkins

This document covers the services available on ci.jenkins.io and our internal trusted.ci instance.

Node Labels

We use node labels to define capabilities of the nodes in our Jenkins clusters.

These labels are a "contract" between ci.jenkins.io’s infrastructure maintainers and users. The implementation of agent "types" can vary depending on the underlying infrastructure: it can be containers, virtual machines, in different locations.

All agents are ephemeral and are destroyed once a build is finished (wether it’s successful or failed).

  • If you are building a plugin, the node/agent specification is abstracted by the pipeline library function buildPlugin() (https://github.com/jenkins-infra/pipeline-library#buildplugin) which must be used. Please note that it is not recommended to use the pipeline instructions specific to Kubernetes (such as podTemplate() or agent { kubernetes {}}} unless you really need it (e.g. if the default set of container agent templates does not fit your needs). The reason is related to the ability of quickly moving the workload to another kind of agents (either VMs, Azure Containers, etc.).

  • Otherwise you have access to the labels described below.

Tools Labels

These labels are defining requests for agent by specifying required tooling:

  • [Recommended for Linux] maven-17: A maven 3 Linux container with JDK17

  • [Recommended for Windows] maven-17-windows: A maven 3 Windows container with JDK17

  • [Recommended for non-Java Linux] node, ruby, webbuilder: A NodeJS + NPM + Ruby (3) Linux container (with ASDF available)

  • [Recommended for Docker Linux containers] docker && linux-amd64

  • maven-11: A maven 3 Linux container with JDK11

  • maven-11-windows: A maven 3 Windows container with JDK11

  • maven-21: A maven 3 Linux container with JDK21

  • maven-21-windows: A maven 3 Windows container with JDK21

  • maven-21: A maven 3 Linux container with JDK21

  • [Legacy only] maven: A Maven 3 Linux container with JDK8

  • [Legacy only] maven-windows: A maven 3 Windows container with JDK8

Docker Labels

Docker requires a Virtual Machine to run with enough safety (as most of the workloads requires both a build and a run of a container).

The following labels are provided:

  • docker: spawns a Linux (x86) VM agent with a Docker Engine Community Edition available

  • arm64docker: spawns a Linux ARM64 VM agent with a Docker Engine Community Edition available

  • docker-windows-2022: spawns a Windows 2022 VM with Docker Windows Container feature enabled (and Docker Community Edition)

  • docker-windows-2019: spawns a Windows 2019 VM with Docker Windows Container feature enabled (and Docker Community Edition)

Advanced Labels

More labels are provided to cover advanced use cases. Please use these labels with cautious (because of the cost and the non stability of these labels):

Node Labels - Processors

  • amd64: An agent running an AMD or Intel 64 bit processor

  • arm64: An agent running an ARM 64 bit processor on AWS (Amazon Graviton)

  • s390x: An agent running an IBM System 390x (Z series) processor

Container / VM Labels

This is avery advanced use case. You can trigger the "type" of agent with very specific

  • vm: spawns a Virtual Machine Agent. Usually it is a 4 vCPUs and 16 Gb memory machine.

  • container: spawns a container Agent. Usually limited to 4 vCPUs and 8 Gb memory.

  • highmem: spawns a Virtual Machine agent with 8 vCPUs and 32 Gb of memory. Avoid it unless really required (costs a lot).

Cloud Labels

Please note that these labels are not always guaranteed (depends on the cloud billing and availability)

For Azure:

  • azure: spawns a VM agent in Azure

  • aci: spawns a container agent in Azure ACI

  • ci.jenkins.io-agents-1: spawns a kubernetes agent in Azure

Operating System Labels

  • ubuntu-22.04: spawns an Ubuntu 22.04 LTS Virtual Machine agent

  • windows-2019: spawns a Windows Server LTSC 2019 Virtual Machine Agent

  • windows-2022: spawns a Windows Server LTSC 2022 Virtual Machine Agent

Tool Installers

The following Jenkins tool installers are provided:

  • jdk8 A recent OpenJDK 8 version from java adoptium

  • jdk11 A recent OpenJDK 11 version from java adoptium

  • jdk17 A recent OpenJDK 17 version from java adoptium

  • jdk21 A recent OpenJDK 21 version from java adoptium

  • mvn A recent Maven 3.x version

  • groovy A recent Groovy 2.x version

[!NOTE] JDK support on ci.jenkins.io is driven by the "2+2+2" lifecycle as described in jenkinsci/jep#400

Caching mirrors

https://repo.jenkins-ci.org/nodejs-dist/ and https://repo.jenkins-ci.org/npm-dist/ mirror https://nodejs.org/dist/ and http://registry.npmjs.org/npm/-/, respectively, so these may be used from frontend-maven-plugin, as happens automatically in the plugin parent POM as of 2.29. (There is currently no mirror for https://github.com/yarnpkg/yarn/releases/download/, the yarn distribution site.)

There is also a mirror of the npm package repository; to use it:

npm config set registry https://repo.jenkins-ci.org/api/npm/npm/

or

yarn config set -- --registry https://repo.jenkins-ci.org/api/npm/npm/

Artifact Caching Proxy

The artifact caching proxy is a mechanism we’ve put in place using nginx proxy in front of repo.jenkins-ci.org (our JFrog sponsored Artifactory instance) and Maven Central to cache artifact download requests.

The main goals are to decrease the consumed bandwidth (many terabytes per month) and to increase Jenkins infrastructure reliability and resilience.

In case you need for whatever reason to disable this mechanism (discouraged), you have two possibilities:

Ex:

buildPlugin(
  useContainerAgent: true, // Set to `false` if you need to use Docker for containerized tests
  useArtifactCachingProxy: false,
  configurations: [
    [platform: 'linux', jdk: 17],
    [platform: 'windows', jdk: 11],
])