Proposal: Docker packaging changelogs

[Oleg Nenashev]

Hi all,

As many of Docker adopters know, we do not regularly put packaging changelogs to Jenkins release notes: https://jenkins.io/changelog/. Unless something goes really wrong, users have no practical way to know what has changed in Docker packaging, and they have to go to the commit history and somehow track down the commit used for their Jenkins version. It is a natural follow-up to the Continuous Delivery we use for Docker images, but is not convenient for many users. Docker packaging is a mission-critical deliverable for the Jenkins project, and I believe users deserve to see the changelogs tehere and to see cool features we deliver there (like recent official CentOS images).

I would like to propose adding changelog for Docker releases. I have 2 versioning options in mind:

Option 1:

• We introduce independent versioning for Docker packaging. This versioning follows the semver approach, and we start from 2.0.0 or any similar version which is explicitly different from Jenkins versioning
• Release versions are considered as experimental, delivery pipelines keep using latest versions and commit references as before
  
• If the experiment gets positive user feedback, we review options to align Docker packaging versions and Jenkins 

Option 2:

• We retrospectively follow Jenkins LTS versioning. Docker packaging version changelogs are released when we de-facto know what went to LTS  
  
• Such approach might be more convenient for LTS users, and we can lnk changelogs from Jenkins release notes
• If the approach is well accepted by users, we can again reconsider the implementation to make versions a part of the delivery pipeline

I have submitted https://github.com/jenkinsci/docker/pull/856 which enables semver changelogs for Docker packaging. If the experiment is successful, we could do similar change in https://github.com/jenkinsci/packaging .

I would appreciate feedback about the proposed options.

Thanks in advance,

Oleg

[Gavin]

Shouldn't there be a 1:1 or 1:many relationship between a Jenkins release and docker release?

Jenkins 2.150 should map to jenkinsci/Jenkins:2.150 docker image (I forgot the docker url but should be similar)

Maybe 2.150-1 if a docker specific fix need to go out?

If so, wouldn't those changes be appropriate to tie to the same version in the changelog? Maybe with a docker label/pill to say it's docker only.

Gavin

--
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/CAPfivLD%3D0PDCEe96ERFSAmxk7Uinmy91_G7DaBgHymcT%3DphVRA%40mail.gmail.com.

[slide]

I think the tags in dockerhub would remain tied to a version of Jenkins, meaning you could still do jenkins/jenkins:2.185-slim to get a Jenkins 2.185 version. I think this is more for changelog info and releases on the github to "tag" the changes that are occurring in the scripts and infra to build the image. People would be able to see changes in ENV and ARG items and so forth that only relate to the docker images themselves. I am not sure how this would be notated in a tag on dockerhub, maybe that needs to be spelled out more in the proposal.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.

[Oleg Nenashev]

There is a direct 1:1 mapping between Jenkins versions and Docker tags. But there is no mapping between Jenkins versions and Docker packaging flow. Basically one can take Docker packaging from the GitHub repo and build an image for any Jenkins version by setting ARGs.

That's why I use the "Docker packaging changelog" term. Sorry if this is still confusing

On Wednesday, July 24, 2019 at 1:47:35 AM UTC+2, slide wrote:

I think the tags in dockerhub would remain tied to a version of Jenkins, meaning you could still do jenkins/jenkins:2.185-slim to get a Jenkins 2.185 version. I think this is more for changelog info and releases on the github to "tag" the changes that are occurring in the scripts and infra to build the image. People would be able to see changes in ENV and ARG items and so forth that only relate to the docker images themselves. I am not sure how this would be notated in a tag on dockerhub, maybe that needs to be spelled out more in the proposal.

On Tuesday, July 23, 2019 at 4:26:32 PM UTC-7, Gavin Mogan wrote:

Shouldn't there be a 1:1 or 1:many relationship between a Jenkins release and docker release?

Jenkins 2.150 should map to jenkinsci/Jenkins:2.150 docker image (I forgot the docker url but should be similar)

Maybe 2.150-1 if a docker specific fix need to go out?

If so, wouldn't those changes be appropriate to tie to the same version in the changelog? Maybe with a docker label/pill to say it's docker only.

Gavin

On Tue., Jul. 23, 2019, 2:38 p.m. Oleg Nenashev, <o.v.n...@gmail.com> wrote:

Hi all,

As many of Docker adopters know, we do not regularly put packaging changelogs to Jenkins release notes: https://jenkins.io/changelog/. Unless something goes really wrong, users have no practical way to know what has changed in Docker packaging, and they have to go to the commit history and somehow track down the commit used for their Jenkins version. It is a natural follow-up to the Continuous Delivery we use for Docker images, but is not convenient for many users. Docker packaging is a mission-critical deliverable for the Jenkins project, and I believe users deserve to see the changelogs tehere and to see cool features we deliver there (like recent official CentOS images).

I would like to propose adding changelog for Docker releases. I have 2 versioning options in mind:

Option 1:

• We introduce independent versioning for Docker packaging. This versioning follows the semver approach, and we start from 2.0.0 or any similar version which is explicitly different from Jenkins versioning
• Release versions are considered as experimental, delivery pipelines keep using latest versions and commit references as before
  
• If the experiment gets positive user feedback, we review options to align Docker packaging versions and Jenkins 

Option 2:

• We retrospectively follow Jenkins LTS versioning. Docker packaging version changelogs are released when we de-facto know what went to LTS  
  
• Such approach might be more convenient for LTS users, and we can lnk changelogs from Jenkins release notes
• If the approach is well accepted by users, we can again reconsider the implementation to make versions a part of the delivery pipeline

I have submitted https://github.com/jenkinsci/docker/pull/856 which enables semver changelogs for Docker packaging. If the experiment is successful, we could do similar change in https://github.com/jenkinsci/packaging .

I would appreciate feedback about the proposed options.

Thanks in advance,

Oleg

--
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 jenkin...@googlegroups.com.

[Gavin]

Yea it's not the changelog for the docker images but the changelog for the tool that builds it. I don't have a suggestion but does make sense. Maybe in addition to GitHub releases, a changelog entry is added to indicate this point forward at least will have the change or something?

But yea. Release notes make sense now

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/d01c6753-13ce-4c3e-a797-3d082ce108f1%40googlegroups.com.

[Oleg Nenashev]

I tried to document it in  https://github.com/jenkinsci/docker/pull/856 , will appreciate suggestions about better wording

You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/KvV_UjU02gE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_Duv2PTCFt3nux8DbQBMxqH-XKq-C8evVtPmHTBBWZuykAw%40mail.gmail.com.

[Oleg Nenashev]

After some investigation, I see no good way to implement Option 2 (linking to LTS).

The publishing scripts work retrospectively, so new Docker packaging version can be applied to previous releases.

I will proceed with Option 1 as an experiment, with versions 0.x.x (semver).

I will start versioning from 0.10.0 so that we can add some retrospective versions later (e.g. for CentOS support)

BR, Oleg

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/d01c6753-13ce-4c3e-a797-3d082ce108f1%40googlegroups.com.

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/KvV_UjU02gE/unsubscribe.

To unsubscribe from this group and all its topics, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.

[Daniel Beck]

> On 27. Jul 2019, at 01:55, Oleg Nenashev <o.v.ne...@gmail.com> wrote:
>
> The publishing scripts work retrospectively, so new Docker packaging version can be applied to previous releases.
>

We do not replace previously published images though…?

[Oleg Nenashev]

Hi Daniel,

Yes, it looks like we don't do it. New images can be added tho if not configured properly (e.g. CentOS was added in Weekly, but we definitely messed up JDK 11 images last year).

Would it be possible to retrieve commit IDs for the recent LTS releases from Trusted CI? If so, I will try to build a draft changelog.

For future releases I will just add commit ID reference to the image directly so that we can track it down easily.

BR, Oleg

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/KvV_UjU02gE/unsubscribe.

To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/E2AF514E-5263-48EB-B29E-D1EEE9CF7A94%40beckweb.net.

[Daniel Beck]

> On 27. Jul 2019, at 13:20, Oleg Nenashev <o.v.ne...@gmail.com> wrote:
>
> Yes, it looks like we don't do it.

For reference https://github.com/jenkinsci/docker/blob/18edef8b4d9ad680d49f4069de96457dc7343882/publish.sh#L217

[Daniel Beck]

> On 27. Jul 2019, at 13:20, Oleg Nenashev <o.v.ne...@gmail.com> wrote:
>

> Would it be possible to retrieve commit IDs for the recent LTS releases from Trusted CI? If so, I will try to build a draft changelog.

No. We don't keep the builds, but I'd be surprised if there are so frequent changes to the images you cannot determine the revision based on the image creation datetime on Dockerhub.

[Oleg Nenashev]

Ok, will do

[Oleg Nenashev]

Meanwhile, I have deployed changelogs for 2 latest LTS baselines to https://github.com/jenkinsci/docker/releases

2.176.3 will be an autogenerated one, more or less

BR, Oleg

On Sunday, July 28, 2019 at 8:41:08 AM UTC+2, Oleg Nenashev wrote:

Ok, will do