Publish Docker controller LTS images from a `stable-<release-line>` branch

[lemeurherve]

What

After discussions with @dduportal, we're proposing to publish LTS releases from their own stable branches like what is done in https://github.com/jenkinsci/packaging & https://github.com/jenkins-infra/release.

Current process of a Docker controller release on LTS publication day:

• Wait for the WAR to be available in repo.jenkin-ci.org
• Manually create an annotated tag from master branch (by a member of @jenkinsci/team-docker-packaging), which trigger a build and publication of the image on trusted.ci.jenkins.io
• Wait for tags publication on Docker Hub
• Manually create the corresponding GitHub release in https://github.com/jenkinsci/docker

Why?

This would have the following immediate and future¹ advantages:

• Align Docker controller image publication on the Core packaging and releasing process
• Avoid mistakes and unexpected changes (like Weekly 2.545 images have been published with JDK17 tags by mistake #2182)
• Allow to ship changes in Weekly faster (shortening the feedback loop) while keeping LTS branch stable²
• Allow to test a stable LTS RC docker image build on ci.jenkins.io, like what is done for Jenkins Core, packaging and release during the LTS release checklist
• Facilitate changelogs and upgrade guides redaction (with the use of labels) cf LTS 2.541.1 changelog and upgrade guide jenkins-infra/jenkins.io#8690 (comment)
• Reduce friction between maintainers, release and infra actors

The inconvenient is the backport hard requirement, which would have to be done when initiating the stable branch and before each LTS "point" release.

How

On LTS publication day:

* Wait for the WAR to be available in repo.jenkin-ci.org
-* Manually create an annotated tag from `master` branch (by a member of @jenkinsci/team-docker-packaging), which trigger a build and publication of the image on trusted.ci.jenkins.io
+* Manually create an annotated tag from `stable-<release-line>` branch (by a member of @jenkinsci/team-docker-packaging), which trigger a build and publication of the image on trusted.ci.jenkins.io
* Wait for tags publication on Docker Hub
* Manually create the corresponding GitHub release in https://github.com/jenkinsci/docker

Plan

For incoming LTS 2.541.1 release (2026-01-21)

• Create a stable-2.541 branch based on the commit of the 2.541 release (baseline)

  • https://github.com/jenkinsci/docker/tree/stable-2.541

    Details

    $ git clone https://github.com/jenkinsci/docker/ docker---stable
    Cloning into 'docker---stable'...
    remote: Enumerating objects: 13624, done.
    remote: Counting objects: 100% (10/10), done.
    remote: Compressing objects: 100% (10/10), done.
    remote: Total 13624 (delta 3), reused 6 (delta 0), pack-reused 13614 (from 2)
    Receiving objects: 100% (13624/13624), 2.59 MiB | 24.07 MiB/s, done.
    Resolving deltas: 100% (5883/5883), done.
    
    $ cd docker---stable 
    
    $ git checkout -b stable-2.541 1d22f3716cc2a5baeedeb636a006c4c38d35ce4c
    Switched to a new branch 'stable-2.541'
    
    $ git push -u origin stable-2.541:stable-2.541
    Total 0 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)
    remote: 
    remote: Create a pull request for 'stable-2.541' on GitHub by visiting:
    remote:      https://github.com/jenkinsci/docker/pull/new/stable-2.541
    remote: 
    To https://github.com/jenkinsci/docker/
     * [new branch]      stable-2.541 -> stable-2.541
    branch 'stable-2.541' set up to track 'origin/stable-2.541'.

• Backport required changes from master to stable-2.541

  • See proposed plan at Publish Docker controller LTS images from a stable-<release-line> branch #2195 (comment)
  • Similar to the work we (infra team) did for LTS 2.541.1 release checklist jenkins-infra/release#811 cf Backport from master (Weekly) in stable-2.541 for LTS 2.541.1 jenkins-infra/release#833 template changes:
    • Backport of packaging in stable-2.541 for LTS 2.541.1 packaging#728
    • Backport from master (Weekly) in stable-2.541 for LTS 2.541.1 jenkins-infra/release#833
  • Merge backport PRs
  • Ensure stable branch build is passing on ci.jenkins.io: https://ci.jenkins.io/job/Packaging/job/docker/job/stable-2.541/6 ✅

• Mention backports in LTS release checklist:

  • Checklist updated and comment posted at LTS 2.541.1 release checklist jenkins-infra/release#811 (comment)

On Day -1

• Check no additional backport is required
• Check stable branch build is passing on ci.jenkins.io: https://ci.jenkins.io/job/Packaging/job/docker/job/stable-2.541
  • https://ci.jenkins.io/job/Packaging/job/docker/job/stable-2.541/7 ✅

On release day

• Create and push annotated tag from stable-2.541
  • Details

    $ git checkout stable-2.541
    $ git log -1 --oneline
    1122ed9 (HEAD -> stable-2.541, tag: 2.541.1, upstream/stable-2.541) Merge pull request #2227 from lemeurherve/backport-fix-war-sha
    $ git tag -m 2.541.1 -a 2.541.1
    $ git push upstream 2.541.1     
    Enumerating objects: 1, done.
    Counting objects: 100% (1/1), done.
    Writing objects: 100% (1/1), 175 bytes | 87.00 KiB/s, done.
    Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)
    To https://github.com/jenkinsci/docker.git
     * [new tag]         2.541.1 -> 2.541.1

• Wait or trigger a "Scan Repository" on trusted.ci.jenkins.io docker controller job
  • Ensure only the new tag is taken in account
• Ensure tags are published on Docker Hub
• Publish GitHub release

  • https://github.com/jenkinsci/docker/releases/tag/2.541.1

  • Note: I manually attached build result metadata of Linux images to this release

Afterward

• Ensure there is no dependencies bumps to stable branches
  • updatecli:
    • chore(github): run updatecli workflow only on commits or PRs targeting master branch #2215
    • backport(github): run updatecli workflow only on commits or PRs targeting master branch (#2215) #2221
  • Dependabot: already configured to check only masterbranch
• Add branch protections to stable branches: Publish Docker controller LTS images from a stable-<release-line> branch #2195 (comment)
• Add an entry about this backport in:
  • LTS 2.541.1 release checklist jenkins-infra/release#811
    • Checlist updated and comment posted at LTS 2.541.1 release checklist jenkins-infra/release#811 (comment)
  • https://github.com/jenkins-infra/release/blob/master/.github/ISSUE_TEMPLATE/1-lts-release-checklist.md
    • chore(release-checklist): add docker controller backport (master) jenkins-infra/release#871
  • https://github.com/jenkins-infra/release/blob/stable-2.541/.github/ISSUE_TEMPLATE/1-lts-release-checklist.md (backport)
    • chore(release-checklist): add docker controller backport (stable-2.541) jenkins-infra/release#872
• Update init-lts-branch.sh script to create stable-<release-line> in jenkinsci/docker too
  • feat(tools/init-lts-line): create stable branch in jenkinsci/docker too jenkins-infra/release#870

---

WDYT @jenkinsci/team-docker-packaging, @jenkinsci/jenkins-security-team, @timja (as Release Officer), @krisstern (as LTS 2.541.1 co-release lead)?

If most stakeholders are OK with this plan, I'll take care of the branch creation and backport this week.

Refs:

• LTS 2.541.1 release jenkins-infra/helpdesk#4945
• LTS 2.541.1 release checklist jenkins-infra/release#811
• https://github.com/jenkins-infra/release/blob/master/tools/init-lts-line

Footnotes

1. I'll develop ramifications in follow-up comments/issues. ↩

2. Thx Captain Obvious :P ↩

[timja]

Sounds good, consistent with other repositories

[Kevin-CB]

+1, I don’t see any problem with this approach.

[lemeurherve]

As stakeholders from each concerned team approved, I'm proceeding to the creation of stable-2.541 branch from 1d22f37 cf https://github.com/jenkinsci/docker/releases/tag/2.541.

EDIT: branch created: https://github.com/jenkinsci/docker/tree/stable-2.541

[lemeurherve]

I've prepared the backport of commits I think we should include in stable-2.541.

I've splitted them in three parts, to be ideally merged successively for easier potential revert(s).

Proposed backport plan

Backport of base images changes from master to stable-2.541

Pull request:

• Backport of base images changes from master to stable-2.541 #2214
• https://ci.jenkins.io/job/Packaging/job/docker/view/change-requests/job/PR-2214

Includes:

• f9fd9de - Bump Alpine Linux Version to 3.23.2 #2131 [labels: dependencies,alpine,into-lts]
• 2617de2 - Bump UBI9 version to 9.7-1766364927 #2141 [labels: dependencies,into-lts]
• 2a7705c - chore(deps): bump ubi9/ubi from 9.7-1764794285 to 9.7-1766364927 in /rhel/ubi9/hotspot #2144 [labels: dependencies,into-lts]
• 3fa92a5 - Bump RHEL version to 9.7-1767674301 #2177 [labels: dependencies,rhel,into-lts]
• 0977d40 - chore: regroup Debian images #2138 [labels: chore,debian,debian-slim]
  • Backported again in this branch to retrieve DEBIAN_TAG bump to latest 20251117 version that should not have been included in that PR cf 0977d40#r175056649
• c1edbf1 - Bump RHEL version to 9.7-1768785530 #2218 [labels: dependencies,rhel,into-lts]

Those are the "obvious" base images changes to backport into LTS 2.541.1.

• Independent from the other backport pull requests below, this PR should be merged as it is whenever we want, ideally first.

Backport of tooling changes from master to stable-2.541

Pull request:

• Backport of tooling changes from master to stable-2.541 #2212
• https://ci.jenkins.io/job/Packaging/job/docker/view/change-requests/job/PR-2212

See PR body for the list and reasoning of included and rejected commits.

Those are the required changes to backport the new features below.

• If new features backport content is agreed upon, this PR should be merged as it is whenever we want, ideally in second.

Backport of new features changes from master to stable-2.541

Pull request:

• Backport of new features from master to stable-2.541 #2213
• https://ci.jenkins.io/job/Packaging/job/docker/view/change-requests/job/PR-2213

Includes:

• 23db2d9 - feat(windows): build both Windows 2019 and 2022 images #2209 [labels: enhancement,windows,into-lts]
• b8051c8 - feat: add JDK25 images #2146 [labels: enhancement,windows,linux,jdk25,release-version:2.541.1,release-version:2.544,into-lts]

Refs:

• Provide Windows Server 2022 image #2167 (comment)
• provide jdk25 variants #2121 (comment)

Those are the new features changes to backport into LTS 2.541.1 that need to be agreed upon.

• If so, this PR should be merged into stable-2.541 after being rebased on the result of the merge of Backport of tooling changes from master to stable-2.541 #2212, in last

Alternatively (but not personaly favored), it can be merged as it is into stable-2.541 (including #2212 commits), in last.

WDYT @timja @MarkEWaite @dduportal?