Docker LTS image: issue with locale, should we rebuild?

[Damien Duportal]

Hello dear developers and maintainers,

We (the Jenkins Infra team) were recently bitten by a change in the latest Docker image for Jenkins controller, in its LTS 2.303.1 (released last week).

The issue is related to a change of locale from "C.UTF-8" to "POSIX" when using Debian image (as an upstream change from Debian bullseye).

A fix has already been made by a user in https://github.com/jenkinsci/docker/pull/1194 and is already merge in GitHub.

We (the Jenkins Infra team) would like to rebuild the Docker image for the LTS 2.303.1 to avoid our users to be annoyed by this issue.

- It should not imply any tagging version change (as the Docker image tags are only about the Core version of Jenkins used, not about the other dependencies on the image)

- It should only impact the Debian images (amd64 and arm64)

- It should not impact the weekly (next weekly will have the fix of course)

- It should make the image being advertised as updated a few days after the official LTS release

- Is there any issue or counter voice to this change?

- Is there any question or element unclear?

For the Jenkins infra team

Damien DUPORTAL

[Mark Waite]

No issue or objection from me to have the 2.303.1 Debian images updated.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/0e3ad65e-9bd7-4074-9fc6-e35328f837dcn%40googlegroups.com.

[Torsten Walter]

Would be great if you could announce once it's done. So that people who build images based on it have the chance of triggering a re-build.

People who use it in Kubernetes might have a problem with the updated images in case they use image pull policy IfNotPresent.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtFUzjbbxT5jbcFxGW3D52ViNJ3LOwNzeNKFhQOGbEEQnQ%40mail.gmail.com.

[Oleg Nenashev]

I would rather recommend 2.303.2. Docker images are so popular at the moment, I see no reason in separating their versioning from the Jenkins LTS releases.

[Jon Brohauge]

+1 for Olegs recommendation of bumping the build number. Versioned artifacts should be immutable.

[Damien Duportal]

Thanks fro your answers.

If I understand correctly, we would have to bump the Jenkins Core LTS version is that correct?

In that case, I defer to the usual release officer for driving this (that means not before Wednesday as Tuesday is weekly release day).

Damien

[Tim Jacomb]

Hello

Is the suggestion to do a normal LTS release with backporting or just bump the version with the same code and new docker build?

(Any volunteers to run the release? The next scheduled release is on 22nd September)

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/7c27bda5-ee41-4570-b616-abea45fc7832n%40googlegroups.com.

[jn...@cloudbees.com]

> see no reason in separating their versioning from the Jenkins LTS releases.

what would the rationale be as to why this does this necessitate a bump in the LTS?  (

the docker images are (where) published with several tags
`lts` `lts-jdk8`   ok so maybe the `2.203.1` tag you don't want to republish - but that only affects people using an explicit tag that currently expect it to be immutable.
I would suggest that a `2.303.1_2` would be published or something like that along with the generic lts tags if we do not want to replace the `2.303.1` tag.

However going forward we need to make sure people do not think actual tags are immutable" (the only tag that should be immutable is one with an explicit (for the docker build) build number, anything else can be updated and would be just the same as the last `{lts_version}_{latest_build_number)`

I would hate to ask if a seriously exploitable JRE issue came to light, so this does seem like an issue if we are tying LTS jenkins version to an actual package version, thus this is something that should be happening anyway.

If we publish a .2 just for a packaging issue then this will trigger upgrade warnings for all users on Jenkins who have just upgraded, and they will have absolutely zero changes, or we do have changes and then we have LTS with changes out of schedule - and that can impact people that are planning based on a predictable release cycle.  (the same really should hold for all packages)

/James

[Raul Arabaolaza]

I do fully agree with James here, if there is a bug on a concrete image rebuild it, put some classifier on the version so people can understand what is happening and no tags are modified. I do not see the need to rebuild everything but the docker images to generate a new release that is gonna be exactly the same than the previous one but with a different version number  

[Matt Sicker]

Just like the Helm chart version doesn’t match exactly with the Jenkins version. A rebuilt image should use a new version, but it would help to use a naming scheme that doesn’t conflict with real Jenkins release versions.

Matt Sicker

On Sep 2, 2021, at 08:59, Raul Arabaolaza <rarab...@cloudbees.com> wrote:

I do fully agree with James here, if there is a bug on a concrete image rebuild it, put some classifier on the version so people can understand what is happening and no tags are modified. I do not see the need to rebuild everything but the docker images to generate a new release that is gonna be exactly the same than the previous one but with a different version number  

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/c43a5a95-4666-4601-9944-28614abcbe32n%40googlegroups.com.