We would like to announce the renaming of the official Docker images for Jenkins agents. It does not have any immediate impact on Jenkins users, but they are expected to gradually upgrade their instances. This article provides information about the new official names, upgrade procedure, and the support policy for the old images. We will also talk about what’s next for the Docker packaging in Jenkins.
The "slave" term is widely considered inappropriate in open source communities. It has been officially deprecated in Jenkins 2.0 in 2016, but there are remaining usages in some Jenkins components. The JENKINS-42816: Slave to Agent renaming leftovers EPIC tracks cleanup of such usages. Official Docker agent images were a glaring case, it was not easy to fix that with the previous versions of the image release Pipelines on DockerHub. It is great to have the image naming issue finally fixed by this update.
Another notable change is replacing the JNLP agent term with inbound agent. Historically "JNLP" has been used as a name of Remoting protocols. JNLP stands for Java Network Launch Protocol which is a part of the Java Web Start. Jenkins supports Java Web Start mode for agents when running agents on Java 1.8, but our networking protocols are based on TCP and have nothing to do with Java Network Launch Protocol. This name has been very confusing since the beginning and became worse with the introduction of WebSocket support in Jenkins 2.217 (JEP-222). Docker agent images support WebSockets, so we decided to change the image name to jenkins/inbound-agent so that it prevents further confusion. Inbound agent term refers to agent protocols in which the agent initiates the connection to the Jenkins master through different protocols.
Good news, there are no breaking changes caused by this renaming. All images have been already modified to use the new terminology internally. If you use the recent versions of the previous images, you can just replace the old names with the new ones. These names may be referenced in your Dockerfiles, scripts, and Jenkins configurations.
We will keep updating the old images on DockerHub for at least 3 months (until August 05, 2020). There will be no new configurations and platforms added to the old images, but all existing ones will remain available (Debian for Java 1.8 and 11, Alpine for Java 1.8, etc.). After August 05, 2020, the old images will no longer receive updates, but previous versions will remain available to users on DockerHub.
We will continue renaming of the Docker images in Jenkins components which reference old image names.
There is also a set of convenience Docker images which include build tools like Maven or Gradle which will be renamed later.
jenkins/ssh-agent image might be renamed again in the future as well;
see the ongoing discussion in this developer mailing list thread.
If you are rather interested in new features in Jenkins Docker packaging, stay tuned for future announcements! There are multiple ongoing initiatives which you can find on the public Jenkins roadmap (in the draft stage, see JEP-14). Some stories:
General availability of Windows images.
Support for more platforms (AArch64, IBM s390x, PowerPC).
Switching to AdoptOpenJDK.
Introducing multi-platform Docker images.
If you are interested in any of these projects and would like to contribute, please reach out to the Platform Special Interest Group which coordinates initiatives related to Jenkins in Docker.
Regarding the agent terminology cleanup outside Docker images,
we will keep working on this project in the Advocacy & Outreach SIG.
If you see the usage of the obsolete "slave" term anywhere in the Jenkins organization (Web UI, documentation, etc.),
please feel free to submit a pull request or to report an issue in the JENKINS-42816: Slave to Agent renaming leftovers EPIC.
There are "just" 3000 occurences left in the
jenkinsci GitHub organization, but we will get there.
Any contributions will be appreciated!