Automate Docker Image Release during the packaging build

[dduportal]

Any Core release should automatically create the (annotated) tag and publish the release in jenkinsci/docker to automate the release process described in the

release/docs/releases.md

Lines 277 to 289 in 6a55156

	### Publish Docker image
	⚠️ **Requires write access to the [jenkinsci/docker repository](https://github.com/jenkinsci/docker) ** ⚠️
	💡 **Access to the network containing trusted.ci.jenkins.io could help in case of error but is not mandatory** 💡
	Create a new tag in the [jenkinsci/docker repository](https://github.com/jenkinsci/docker) with the value of the released core version:
	- `git tag --annotate --message="2.VVV.V" 2.VVV.V`
	- `git push upstream 2.VVV.V`
	Publish a release on GitHub associated with the tag pushed.
	The [Container image job in trusted.ci.jenkins.io](https://trusted.ci.jenkins.io:1443/job/Containers/job/Core%20Release%20Containers) should detect the tag in the next 15 minutes and automatically publish it to the DockerHub.
	**Note**: If you do not have access to the network trusted.ci.jenkins.io is in, ask a release team or infrastructure team member to start the job for you. Access to the VPN is not sufficient.

documentation.

This issue is NOT about building the Docker image in release.ci.jenkins.io: it's tracked in jenkins-infra/helpdesk#2845 as a separate topic (because release.ci does not have agents with a Docker CE Engine today).

[dduportal]

Release publication can be done with gh CLI:

• https://cli.github.com/manual/gh_release_edit
• Something like gh release edit <new core version> --draft=false --tag=<new core version> --latest

[MarkEWaite]

Release publication can be done with gh CLI:

• https://cli.github.com/manual/gh_release_edit
• Something like gh release edit <new core version> --draft=false --tag=<new core version> --latest

I think that may need a safeguard so that it does not publish LTS releases or security releases with the same technique. Weekly releases can take the most recent draft changelog. LTS and security changelogs are hand-crafted, even on GitHub.

[timja]

LTS and security changelogs are hand-crafted,

LTS ones follow a very strong pattern though and could just have a template supplied, if someone wants to polish it they can do that after, better to minimise human interaction required delaying the docker release etc.

If it's important it's not update then it could just do a tag and release notes added later.

[MarkEWaite]

LTS and security changelogs are hand-crafted,

LTS ones follow a very strong pattern though and could just have a template supplied, if someone wants to polish it they can do that after, better to minimise human interaction required delaying the docker release etc.

Agreed. It can be automated for LTS releases as you said. They follow a very consistent pattern.

[dduportal]

Scheduling constraint we met during yesterday weekly release (2.414):

The tag on jenkinsci/docker must be created only after the WAR file is available in get.jenkins.io to avoid the curl: (22) The requested URL returned error: 404 error message in the Docker image build (when downloading the aformentionned WAR file).

[lemeurherve]

@MarkEWaite @timja @dduportal this message to let you know that I'm interested to take a look at this.

---

EDIT (2026 as simple edit not needing a new comment): related:

• Question: image release process to Docker registry jenkinsci/docker#1463 (comment)

[dduportal]

Remark from @daniel-beck : this automation should tolerate the tag already existing and continue