new LTS release and recent weekly #544
Conversation
|
Wow, 55 separate versions. Is there a point at which there will be less versions? Since these are weekly versions would it make sense to stick to just 6 months of weekly and 2-3 LTS versions? |
|
I'd really love to get some Jenkins user feedback on this. I know I haven't run into any serious plugin compatibility issues myself, and definitely not to the level of needing six full months worth of weekly releases to track down something that works. |
|
I have customer to run various jenkins version. Most of them do use LTS but others may run a weekly ... 8 months old. As the Dockerfile are generated via a stackbrew script I don't get the issue with this approach, as this ensure all tags get a common usage. |
|
Build test of #544; 26cec21 ( $ url="https://raw.githubusercontent.com/docker-library/official-images/26cec21018af5533bb31b8e602b0019c90539d23/library/jenkins"
$ bashbrew build "$url"
Fetching jenkins (git://github.com/cloudbees/jenkins-ci.org-docker) ...
Processing jenkins:1.554.1 ...
Processing jenkins:1.554.2 ...
Processing jenkins:1.554.3 ...
Processing jenkins:1.555 ...
Processing jenkins:1.556 ...
Processing jenkins:1.557 ...
Processing jenkins:1.558 ...
Processing jenkins:1.559 ...
Processing jenkins:1.560 ...
Processing jenkins:1.561 ...
Processing jenkins:1.562 ...
Processing jenkins:1.563 ...
Processing jenkins:1.564 ...
Processing jenkins:1.565.1 ...
Processing jenkins:1.565.2 ...
Processing jenkins:1.565.3 ...
Processing jenkins:1.565 ...
Processing jenkins:1.566 ...
Processing jenkins:1.567 ...
Processing jenkins:1.568 ...
Processing jenkins:1.569 ...
Processing jenkins:1.570 ...
Processing jenkins:1.571 ...
Processing jenkins:1.572 ...
Processing jenkins:1.573 ...
Processing jenkins:1.574 ...
Processing jenkins:1.575 ...
Processing jenkins:1.576 ...
Processing jenkins:1.577 ...
Processing jenkins:1.578 ...
Processing jenkins:1.579 ...
Processing jenkins:1.580.1 ...
Processing jenkins:1.580.2 ...
Processing jenkins:1.580.3 ...
Processing jenkins:latest ...
Processing jenkins:1.580 ...
Processing jenkins:1.581 ...
Processing jenkins:1.582 ...
Processing jenkins:1.583 ...
Processing jenkins:1.584 ...
Processing jenkins:1.585 ...
Processing jenkins:1.586 ...
Processing jenkins:1.587 ...
Processing jenkins:1.588 ...
Processing jenkins:1.589 ...
Processing jenkins:1.590 ...
Processing jenkins:1.591 ...
Processing jenkins:1.592 ...
Processing jenkins:1.593 ...
Processing jenkins:1.594 ...
Processing jenkins:1.595 ...
Processing jenkins:1.596 ...
Processing jenkins:1.597 ...
Processing jenkins:1.598 ...
Processing jenkins:1.599 ...
Processing jenkins:1.600 ...
Processing jenkins:weekly ...
$ bashbrew list "$url" | xargs test/run.sh
testing jenkins:1.554.1
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.554.2
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.554.3
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.555
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.556
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.557
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.558
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.559
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.560
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.561
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.562
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.563
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.564
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.565.1
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.565.2
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.565.3
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.565
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.566
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.567
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.568
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.569
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.570
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.571
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.572
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.573
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.574
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.575
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.576
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.577
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.578
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.579
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.580.1
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.580.2
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.580.3
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:latest
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.580
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.581
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.582
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.583
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.584
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.585
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.586
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.587
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.588
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.589
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.590
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.591
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.592
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.593
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.594
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.595
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.596
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.597
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.598
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.599
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.600
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed
testing jenkins:weekly
'utc' [1/2]...passed
'cve-2014--shellshock' [2/2]...passed |
|
LGTM |
I'd point out these issues that I see with your approach:
The first two items may be partially mitigated by layer caching on the build servers, but the bulk of each of these images beyond what the base The third item is something that could be improved, but I honestly don't know what a user who has to scroll through two+ screens of Jenkins tags on that page is supposed to think. I wish that Docker Hub published pull statistics on a per-tag basis, but I strongly suspect most people are downloading |
|
@md5 stop me if I'm wrong, but
|
|
I'm jumping in here, but it could be interesting to have two repositories : jenkins-weekly and jenkins-lts, just to ease people's life, to answer @md5 's concern about scrolling lots of pages ;) My 2 cents, |
|
@ndeloof so looking at http://jenkins-ci.org/, it's only showing 1.602 and 1.596.1. It sounds like you'd be fine with the docs on Docker Hub showing only those two versions, as long as you can still rebuild new images of the old versions as needed (back to some unspecified oldest version). Is that accurate? As for the setup of the official build server, I only know what I've gleaned from Github since I don't have any official involvement with the team running the official images program. Perhaps I should not have speculated about that part of it since I may have been speaking out of turn. |
|
I'd be fine ton only list the most recent version on dockerhub page, but don't have control over this. @Vlatombe tags are designed for this usage. We already have "weekly" and "latest" (i.e. LTS) |
|
@ndeloof Yes I agree, I guess in the end it is down to a usability issue of the https://registry.hub.docker.com/_/jenkins/tags/manage/ page when the repositories contains loads of tags ;) |
|
A few points:
|
|
by the way, Jenkins has a new LTS (1.596.1) so this PR needs another small update :) |
|
... as well as many new weekly release. |
|
Looks like @yosifkit already gave this a LGTM, so it's just waiting on another from @tianon or @Moghedrin. I still don't think that having all these old releases available in this way is a good idea, but that situation was already accepted when the Apologies for bike-shedding. |
|
P.S. I really think the UX will be better if you merge jenkinsci/docker#71 and regenerate the library file from that. At least then the releases you actually want people to download will be listed first. |
|
Nevermind about @yosifkit's LGTM, I see this in the Travis output after your latest push: |
|
applied your proposed UI PR |
|
I just realized that the output is incorrect for the current weekly and LTS releases. It's missing the directory name. I'll fix that and send you a new PR. Sorry! |
|
oh, indeed. np, I should have reviewed this more carefully :) |
|
The review is taking so long precisely because of the large number of
discrete tags, so I disagree that discussing it is off-topic.
Smaller sets of tags are much easier and faster to review (see crate's PRs
for a great example of that working in practice).
|
|
all those tags are created from a template as you suggested earlier, based on postgres sample IIRC |
|
@ndeloof can you re-run the script so we can get a clean Travis build? @tianon I hear what you're saying, but in this case the actual git tag has only changed for the newly added releases. If those releases had each been submitted as their own PR, the review of them could have been quick. That being said, in the case that the template actually does change in a way that the git tag updates for every Docker tag, then I agree that the amount of work involved increases. |
|
Then it would make more sense running the generation script is made on your side and the pull request is just some minor metadata update : either changes to the template (simple revue, all images generation) or just new version added to metadata with no template changes (trivial revue) |
|
@ndeloof Not sure how much of your comment was directed at me, if any. I'll just re-emphasize as I mentioned before that I'm not a maintainer of the |
|
@ndeloof, could you go review and merge jenkinsci/docker#74 so that we can then get a working set here 🙏? |
|
I'm having discussion with my colleague Michael Neale on way to avoid continuous updates for weekly release. Will create a fresh new PR as we went into a reasonable conclusion |
|
I think this is a signal that the weekly release each having its own tag isn't going to work with this process. I recommend just having LTS here and a big sign (somehow) saying to use jenkinsci/jenkins: for a specific weekly version if someone really needs it. Otherwise have a "weekly" tag which changes week to week (but I think that is out of favour). |
|
I think a |
|
tags for every LTS is entirely reasonable - as people do care about those On Wed, Mar 18, 2015 at 9:27 AM yosifkit [email protected] wrote:
|
|
@yosifkit 👍 I think that sounds really reasonable |
|
And also +1 for keeping more versions on a higher-bandwidth separate repo
:+1:
|
|
@michaelneale yeah, I think having |
|
should there be discrete tagged versions for past LTS - like ubuntu also has (that analogy holds - the only difference is jenkins tempo for LTS is faster than ubuntu at the moment - btu the same other wise - people care about those versions). I think weeklies are possibly best somewhere else - or at most - a weekly tag (which is hopefully the latest one - but then, as this is a manual process, like getting an app through the app store, weekly is probably too frequent for this repo). |
I disagree with this part. I think having a single |
|
I think something like the below would work perfect and would only be a version bump for the weekly (which should be like a 5 minute review). Then you can keep the LTS versions here for as long as they are supported. As I noted in a previous comment, the versions that drop out of this list will still be available on the Docker hub, just not displayed as "supported" and not rebuilt with any parent image updates. # group: Current Releases
1.596.1: git://github.com/cloudbees/jenkins-ci.org-docker@b75dc1ae86f9aac71fef358e737ae71dab8cc55b 1.596.1
latest: git://github.com/cloudbees/jenkins-ci.org-docker@b75dc1ae86f9aac71fef358e737ae71dab8cc55b 1.596.1
1.605: git://github.com/cloudbees/jenkins-ci.org-docker@b75dc1ae86f9aac71fef358e737ae71dab8cc55b 1.605
weekly: git://github.com/cloudbees/jenkins-ci.org-docker@b75dc1ae86f9aac71fef358e737ae71dab8cc55b 1.605
# group: Previous LTS Releases
1.580.1: git://github.com/cloudbees/jenkins-ci.org-docker@40c3e3f46939b9f9dcf8d46e62fa7daa80485588 1.580.1
1.565.3: git://github.com/cloudbees/jenkins-ci.org-docker@40c3e3f46939b9f9dcf8d46e62fa7daa80485588 1.565.3
1.565.2: git://github.com/cloudbees/jenkins-ci.org-docker@f313389f8ab728d7b4207da36804ea54415c830b 1.565.2
1.565.1: git://github.com/cloudbees/jenkins-ci.org-docker@f313389f8ab728d7b4207da36804ea54415c830b 1.565.1
1.554.3: git://github.com/cloudbees/jenkins-ci.org-docker@40c3e3f46939b9f9dcf8d46e62fa7daa80485588 1.554.3
1.554.2: git://github.com/cloudbees/jenkins-ci.org-docker@f313389f8ab728d7b4207da36804ea54415c830b 1.554.2
1.554.1: git://github.com/cloudbees/jenkins-ci.org-docker@f313389f8ab728d7b4207da36804ea54415c830b 1.554.1 |
|
I'd add that the only Ubuntu releases included are ones that are still
explicitly supported upstream (ie, are receiving updates for security, etc).
|
|
@yosifkit I'm not sure exactly how Jenkins LTS releases work, but it seems like having only the latest 1.M.N tag per "1.M" would make more sense. |
|
I was just copying what was currently there minus all the old weekly versions, so I am unsure on which are still supported upstream. |
|
Generally updates are for the last few LTSes. Not so much for weeklies (I The lts versions are chosen from weeklies - one weekly gets picked to be Hope that clears things up a bit. So it sounds like LTS, with latest tag, and past LTS tags is easily doable. For weeklies - it is mentioned other projects do this (eg io.js) So that is
|
|
They don't have a concept of "LTS" or "weekly" for See a list of the |
|
Also note the older tags at
https://registry.hub.docker.com/_/iojs/tags/manage/, thanks to tagging each
version explicitly with the full version number.
|
|
@tianon is there a tag for each weekly release? |
|
Not sure exactly what you mean, but as you can see there, each version is tagged multiple times. #543 is a good example PR for a representative update to that image -- the |
|
So what is the trouble that started all this? too many tags in a PR? |
as discussed on docker-library/official-images#544
No description provided.