HEADSUP: Breaking change for Docker Pipelines coming on ci.jenkins.io

[R. Tyler Croy]

I have put this off as long as I feel prudent, but later this week I will be
upgrading the Docker Pipeline plugin on ci.jenkins.io from 1.14 to 1.15.1 which
will break Docker Pipelines which rely on the implicit ENTRYPOINT override
behavior which was supposed in 1.14, but removed for 1.15.1
(https://issues.jenkins-ci.org/browse/JENKINS-41316).

I know at least the jenkinsci/docker Pipeline will break due with invocations
such as this one:
https://github.com/jenkinsci/docker/blob/master/Jenkinsfile#L21
See also:
https://github.com/koalaman/shellcheck/blob/master/Dockerfile#L36


From my understanding, the remediation for this upgrade/regression (depending
on your perspective) is to execute:

docker.image('foo').inside('--entrypoint= ') {
sh 'blah'
}


It is not easily knowable what the size and impact of this change is going to
be, so I'm sending this heads up out.

If you have a Jenkinsfile in ci.jenkins.io that relies on
docker.image().inside() or the equivalent in Declarative Pipeline, that
Pipeline may *break* starting on Thursday, April 5th.



Cheers
- R. Tyler Croy

------------------------------------------------------
Code: <https://github.com/rtyler>
Chatter: <https://twitter.com/agentdero>
xmpp: rty...@jabber.org

% gpg --keyserver keys.gnupg.net --recv-key 1426C7DC3F51E16F
------------------------------------------------------

[Jesse Glick]

On Mon, Apr 2, 2018 at 9:52 AM, R. Tyler Croy <ty...@monkeypox.org> wrote:
> If you have a Jenkinsfile in ci.jenkins.io that relies on
> docker.image().inside() or the equivalent in Declarative Pipeline, that
> Pipeline may *break*

These ought to be pretty easy to find for an admin on this server—scan
the log¹ of the last build of every job named `master`, if it were
“successful” (i.e., incl. `UNSTABLE`), looking for the
`withDockerContainer` step. Could you just trigger fresh builds of all
these jobs after the upgrade and notify the owner if the build fails?
Then there is no need for anyone to guess whether they are affected.
Remember that most repository owners have no Job/Build permissions and
thus cannot trivially trigger new builds themselves even if they
suspected a problem—they would need to push a no-op change to the
`master` branch or file a no-op PR.

¹Example: https://ci.jenkins.io/job/Core/job/jenkins-test-harness/job/master/lastSuccessfulBuild/consoleFull

[R. Tyler Croy]

(replies inline)

On Mon, 02 Apr 2018, Jesse Glick wrote:

> On Mon, Apr 2, 2018 at 9:52 AM, R. Tyler Croy <ty...@monkeypox.org> wrote:
> > If you have a Jenkinsfile in ci.jenkins.io that relies on
> > docker.image().inside() or the equivalent in Declarative Pipeline, that
> > Pipeline may *break*
>

> These ought to be pretty easy to find for an admin on this server???scan

> the log¹ of the last build of every job named `master`, if it were

> ???successful??? (i.e., incl. `UNSTABLE`), looking for the

> `withDockerContainer` step. Could you just trigger fresh builds of all
> these jobs after the upgrade and notify the owner if the build fails?

This is not a "pretty easy" task as far as I am concerned. Without tooling for
grep + Script Console abuse for triggering this, I won't be spending any time
on this. There are literally hundreds of other INFRA tasks I would rather
dedicate time to :-/

If Pipelines break, then that's unfortunate and thus this notice. We are not
going to fall behind on further upgrades to Docker Pipeline due to this change
in behavior by the plugin.

I've already expressed my severe displeasure regarding the change which causes
this breaking behavior, but do not plan to spend any time sugar-coating this
for ci.jenkins.io usage.

[R. Tyler Croy]

(replies inline)

On Mon, 02 Apr 2018, R. Tyler Croy wrote:

>
> I have put this off as long as I feel prudent, but later this week I will be
> upgrading the Docker Pipeline plugin on ci.jenkins.io from 1.14 to 1.15.1 which
> will break Docker Pipelines which rely on the implicit ENTRYPOINT override
> behavior which was supposed in 1.14, but removed for 1.15.1
> (https://issues.jenkins-ci.org/browse/JENKINS-41316).

And now, the gripping conclusion to this thread. The ugprade has been
deployed.

[Jesse Glick]

Since you cannot spend a few minutes triggering fresh builds of
potentially affected repositories, and I have no permissions to
directly trigger builds myself, I ran

jenkinsci$ fgrep docker */Jenkinsfile | fgrep -v "'docker'"

and will attempt to look for regressions by filing no-op PRs to the
following repositories identified as of interest to me:

acceptance-test-harness
archetypes
docker
groovy-sandbox
jenkins-test-harness
maven-hpi-plugin
maven-interceptors
plugin-pom
xstream-fork