Update jenkins

[ndeloof]

Following discussion on #544
give up with tagged versions and only expose "latest" and "weekly"

[lamielle]

I've love to see this merged. There is a recent security advisory and version 1.600 is the latest recommended version: https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+2015-02-27

Additionally, dropping ALL versions seems a bit extreme. Jenkins maintains a set of LTS releases which are released every 12 weeks: https://wiki.jenkins-ci.org/display/JENKINS/LTS+Release+Line. This seems like a nice compromise between the constant weekly versions and dropping useful version tags completely.

Could we add the most recent LTS in addition to latest and weekly (as a start)?

[yosifkit]

I am confused by the lack of any tags for version numbers; a user won't be able to pull jenkins:1.596.1 without them.

We had talked about this in #544, and I was understanding that the problem was the sprawl of versions. I agree with @lamielle that it would be nice to keep a set of LTS versions as well as a few weekly versions. As older versions drop off the list here, they will still be available on the hub as their unique tagged version (like jenkins:1.555).

[lamielle]

I apologize for jumping in on this, I didn't realize there was an in depth discussion in #544.

My only concern was to get at least 1.600+ to address the security updates. Thanks for all the time you've put in on this @ndeloof!

[ndeloof]

@yosifkit imho it doesn't make sense to not have the same behavior / README doc for all docker "official" images available on dockerhub. If at some time we prune some of them from this repo to reduce number of tags, then we will break user experience.

[ndeloof]

@yosifkit added 1.596.1 tag - will then only publish "latest LTS" as official docker image tag

[michaelneale]

It seems the docker official image process doesn't mesh well with the jenkins (slightly unusual) release patterns and tempo. Even LTS in jenkins are quite frequent - which is causing some confusion.

If a user wants fine grained versions - it is better if the jenkins project itself maintains this in its own namespaced repo - and keep official for latest LTS (optional tags for versions, if that can work). The reason a user may want very specific versions would be in locating a bug - not an every day occurrence.

[yosifkit]

We are definitely open to having all the supported releases here. Even having a weekly version with its number tagged is fine. I think the biggest problems were that the weekly versions were not updated weekly (https://github.com/docker-library/official-images/pulls?q=is%3Apr+label%3Alibrary%2Fjenkins+) and past unsupported (meaning won't be updated again upstream) releases were kept around.

Looking at upstream's website, the latest "release" (weekly) is 1.605, and the latest "LTS" is 1.596.1. Looking at past releases sorted by "last modified", (http://mirrors.jenkins-ci.org/war/?C=M;O=D and http://mirrors.jenkins-ci.org/war-stable/?C=M;O=D), only one version of each variety is actively released at a time. As we talked about in that other thread, we think it's perfectly reasonable to have latest, 1.605, weekly, and 1.596.1 as tags in this repo, and that the weekly releases are updated weekly (as long as the new weekly replaces the old weekly, ie 1.606 would replace 1.605).

[michaelneale]

What say you @ndeloof ?

[ndeloof]

My point is, as long as this process is a manual review, even the PR is based on an already discussed and polished Dockerfile template, I won't have enough spare cycles to handle this on a weekly basis.

I've proposed to get this image repo moved to jenkinsci OSS community github repo so "someone" can create a PR every week, will be discussed on next governance meeting (April 1st)

[ndeloof]

@yosifkit does anything prevent this PR to be merged ?
even we disagree on the way a docker image should be maintained, even the bundled software isn't "latest", I'd like to move forward and get latest LTS available (previous one has security issues)

[yosifkit]

LGTM, ping @tianon

Build test of #564; e771f21 (jenkins):

$ url="https://raw.githubusercontent.com/docker-library/official-images/e771f21311ef3380442976cc1b6a922bf94e2f51/library/jenkins"
$ bashbrew build "$url"
Fetching jenkins (git://github.com/cloudbees/jenkins-ci.org-docker) ...
Processing jenkins:latest ...
Processing jenkins:1.596.1 ...
$ bashbrew list "$url" | xargs test/run.sh
testing jenkins:latest
    'utc' [1/2]...passed
    'cve-2014--shellshock' [2/2]...passed
testing jenkins:1.596.1
    'utc' [1/2]...passed
    'cve-2014--shellshock' [2/2]...passed

[tianon]

I'd like to be clear that we disagree on the way an official image should be maintained, not a Docker image in general, which is the important distinction here. You are free to maintain anything under jenkinsci/ as you see fit.

This does LGTM for now though -- I agree that we can iterate more post-merge.