Jenkins-Infra pipeline library changes issue

37 views
Skip to first unread message

Richard Bywater

unread,
May 1, 2020, 8:52:16 PM5/1/20
to jenkin...@googlegroups.com
Just wondering if its expected that updates to Jenkins-Infra pipeline library might cause issues on builds that have no changes to pom.xml etc.?

Looks like there was a pipeline library change made between https://ci.jenkins.io/job/Plugins/job/htmlpublisher-plugin/job/PR-56/1/ and https://ci.jenkins.io/job/Plugins/job/htmlpublisher-plugin/job/PR-56/2/ which has broken the build due to library version issues such as :
12:28:10  Failed while enforcing RequireUpperBoundDeps. The error(s) are [
12:28:10  Require upper bound dependencies error for org.slf4j:jcl-over-slf4j:1.7.25 paths to dependency are:
12:28:10  +-org.jenkins-ci.plugins:htmlpublisher:1.23-SNAPSHOT
12:28:10    +-org.slf4j:jcl-over-slf4j:1.7.25
12:28:10  and
12:28:10  +-org.jenkins-ci.plugins:htmlpublisher:1.23-SNAPSHOT
12:28:10    +-org.jenkins-ci.main:jenkins-core:2.222.3
12:28:10      +-org.slf4j:jcl-over-slf4j:1.7.25 (managed) <-- org.slf4j:jcl-over-slf4j:1.7.26

Not sure if there's an issue with my pom.xml or similar that needs fixing but thought it strange it would 
suddenly break.
Any help gratefully received :)
Richard.

Gavin Mogan

unread,
May 1, 2020, 9:02:43 PM5/1/20
to Jenkins Developers

looks like the recommended version changed. You can tell your jenkinsfile to only build your own version and not try newer ones, but I think its better to catch bugs as early as possible.

--
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/CAAy0hwftkMA7_BTaW2tZj1-02WeyyVtWrWtSU6nKWMFP7jk7YA%40mail.gmail.com.

Mark Waite

unread,
May 1, 2020, 9:03:37 PM5/1/20
to jenkinsci-dev
Yes, that's expected, at least in the sense that changes to the pipeline library are applied to repositories unless the repository specifically loads a precise version of the pipeline library.

In this case, the change is a switch from compiling and testing with Jenkins 1.190.x to instead compile and test with Jenkins 2.222.x.  That's part of the ci.jenkins.io buildPlugin() call for recommended configurations.

Usually that hints that it may be time to consider updating the minimum Jenkins version supported by your plugin.

As an example, I did some analysis of the Jenkins installed versions of the git plugin and decided that it is now time to update the minimum Jenkins version required for the git plugin.  The current minimum version is Jenkins 2.138 (yes, that is a very, very old Jenkins version).  The next git plugin release will require at least Jenkins 2.204.

Mark Waite

--

Mark Waite

unread,
May 1, 2020, 9:06:40 PM5/1/20
to jenkinsci-dev
I misspoke, it was previously testing with Jenkins 2.164 and is now testing with 2.222.  Same principles apply.

Richard Bywater

unread,
May 1, 2020, 11:34:40 PM5/1/20
to jenkin...@googlegroups.com
Thanks all - I've got the build to work again by removing recommendedConfigurations and switching to explicitly building the minimum version of Jenkins that is referenced in the pom.xml for now. I also could fix the issue with upping the slf4jversion parameter but it seemed wrong to do this when I don't have any particular reason in the plugin to have that particular version. I guess I kind of expected the bom to handle that type of thing for me but I assume that's tracking what libraries were available for that particular version of Jenkins?

It would be useful if there was some kind of "minimum" configuration version defined which was defined by, say, the earliest LTS version which has greater than x% usage so that you don't have to keep as up-to-date as you seem to have to have to with recommendedConfigurations.

Out of interest, is there a set of criteria about why a version is recommended? By my calculation (and it seems quite high so is possibly wrong) by moving from a minimum version of 2.164.3 to the recommended 2.222.3 would mean that about 60% of current users would drop out of support?

(Sorry if this message seems confused but it kind of echoes my mind at the moment :D)

Richard.

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

Ullrich Hafner

unread,
May 2, 2020, 6:14:47 AM5/2/20
to Jenkins Developers
BTW: this is yet another argument for disabling the enforcer. Or at least add slf4j to the list of ignores. 

Oleg Nenashev

unread,
May 3, 2020, 3:08:17 AM5/3/20
to Jenkins Developers
Changing the recommended LTS baseline was discussed in this thread in Aug 2019. At that point we did not come to a decision, and the topic was frozen for a while. Note that the Pipeline Library documentation is explicit about it: "It is also possible to use a buildPlugin.recommendedConfigurations() method to get recommended configurations for testing. Note that the recommended configuration may change over time, and hence your CI may break if the new recommended configuration is not compatible". So the breaking behavior is expected but indeed undesired. And there is no explicit criteria though I had "latest LTS baseline" as a target when creating this method.

What we could do is to tweak the buildPlugin() logic to ensure that it does not fail the build when newer configuration fails. Instead of that we could send warnings to the pull request via a message or additional Checks status.

Best regards,
Oleg

On Saturday, May 2, 2020 at 12:14:47 PM UTC+2, Ullrich Hafner wrote:
BTW: this is yet another argument for disabling the enforcer. Or at least add slf4j to the list of ignores. 
Am 02.05.2020 um 05:34 schrieb Richard Bywater <ric...@bywater.nz>:

Thanks all - I've got the build to work again by removing recommendedConfigurations and switching to explicitly building the minimum version of Jenkins that is referenced in the pom.xml for now. I also could fix the issue with upping the slf4jversion parameter but it seemed wrong to do this when I don't have any particular reason in the plugin to have that particular version. I guess I kind of expected the bom to handle that type of thing for me but I assume that's tracking what libraries were available for that particular version of Jenkins?

It would be useful if there was some kind of "minimum" configuration version defined which was defined by, say, the earliest LTS version which has greater than x% usage so that you don't have to keep as up-to-date as you seem to have to have to with recommendedConfigurations.

Out of interest, is there a set of criteria about why a version is recommended? By my calculation (and it seems quite high so is possibly wrong) by moving from a minimum version of 2.164.3 to the recommended 2.222.3 would mean that about 60% of current users would drop out of support?

(Sorry if this message seems confused but it kind of echoes my mind at the moment :D)

Richard.

On Sat, 2 May 2020 at 13:06, Mark Waite <mark.e...@gmail.com> wrote:
I misspoke, it was previously testing with Jenkins 2.164 and is now testing with 2.222.  Same principles apply.

On Fri, May 1, 2020 at 7:03 PM Mark Waite <mark.e...@gmail.com> wrote:
Yes, that's expected, at least in the sense that changes to the pipeline library are applied to repositories unless the repository specifically loads a precise version of the pipeline library.

In this case, the change is a switch from compiling and testing with Jenkins 1.190.x to instead compile and test with Jenkins 2.222.x.  That's part of the ci.jenkins.io buildPlugin() call for recommended configurations.

Usually that hints that it may be time to consider updating the minimum Jenkins version supported by your plugin.

As an example, I did some analysis of the Jenkins installed versions of the git plugin and decided that it is now time to update the minimum Jenkins version required for the git plugin.  The current minimum version is Jenkins 2.138 (yes, that is a very, very old Jenkins version).  The next git plugin release will require at least Jenkins 2.204.

Mark Waite

On Fri, May 1, 2020 at 6:52 PM Richard Bywater <ric...@bywater.nz> wrote:
Just wondering if its expected that updates to Jenkins-Infra pipeline library might cause issues on builds that have no changes to pom.xml etc.?

Looks like there was a pipeline library change made between https://ci.jenkins.io/job/Plugins/job/htmlpublisher-plugin/job/PR-56/1/ and https://ci.jenkins.io/job/Plugins/job/htmlpublisher-plugin/job/PR-56/2/ which has broken the build due to library version issues such as :
12:28:10  Failed while enforcing RequireUpperBoundDeps. The error(s) are [
12:28:10  Require upper bound dependencies error for org.slf4j:jcl-over-slf4j:1.7.25 paths to dependency are:
12:28:10  +-org.jenkins-ci.plugins:htmlpublisher:1.23-SNAPSHOT
12:28:10    +-org.slf4j:jcl-over-slf4j:1.7.25
12:28:10  and
12:28:10  +-org.jenkins-ci.plugins:htmlpublisher:1.23-SNAPSHOT
12:28:10    +-org.jenkins-ci.main:jenkins-core:2.222.3
12:28:10      +-org.slf4j:jcl-over-slf4j:1.7.25 (managed) <-- org.slf4j:jcl-over-slf4j:1.7.26

Not sure if there's an issue with my pom.xml or similar that needs fixing but thought it strange it would 
suddenly break.
Any help gratefully received :)
Richard.

--
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.

--
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.

--
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.

Jesse Glick

unread,
May 4, 2020, 9:00:58 AM5/4/20
to Jenkins Dev
On Fri, May 1, 2020 at 11:34 PM Richard Bywater <ric...@bywater.nz> wrote:
> I've got the build to work again by removing recommendedConfigurations and switching to explicitly building the minimum version of Jenkins that is referenced in the pom.xml

This makes no sense. If you _only_ want to build the version
referenced in `pom.xml`, just

buildPlugin()

The point of `configurations` is to build against _newer_ versions as well.

> I also could fix the issue with upping the slf4jversion parameter but it seemed wrong to do this when I don't have any particular reason in the plugin to have that particular version. I guess I kind of expected the bom to handle that type of thing for me

It does. You should switch to a 4.x version of the parent POM.

> the earliest LTS version which has greater than x% usage

We only ship security patches to the current LTS, so anything older is
technically unsupported.

I remain opposed to having an implicit Jenkins version in
`recommendedConfigurations` and in general to the notion of having
plugin `Jenkinsfile`s import an unversioned tip of `pipeline-library`.

Richard Bywater

unread,
May 4, 2020, 8:53:08 PM5/4/20
to jenkin...@googlegroups.com
On Tue, 5 May 2020 at 01:01, Jesse Glick <jgl...@cloudbees.com> wrote:
> I've got the build to work again by removing recommendedConfigurations and switching to explicitly building the minimum version of Jenkins that is referenced in the pom.xml

This makes no sense. If you _only_ want to build the version
referenced in `pom.xml`, just

buildPlugin()

The point of `configurations` is to build against _newer_ versions as well.

Thanks - I didn't realise that. After reading the README https://github.com/jenkins-infra/pipeline-library I wasn't clear on what the default behaviour was if you didn't specify any of the optional arguments. I'm also confused by the statement "Gradle support in buildPlugin() is deprecated and will be eventually removed. Please use buildPluginWithGradle()". Is that actually accurate? Should we be using Gradle builds by default now?
 

> I also could fix the issue with upping the slf4jversion parameter but it seemed wrong to do this when I don't have any particular reason in the plugin to have that particular version. I guess I kind of expected the bom to handle that type of thing for me

It does. You should switch to a 4.x version of the parent POM.

Ah ok. When I was searching I somehow managed to miss https://www.jenkins.io/doc/developer/plugin-development/dependency-management/ and its related links so I'll follow through those pages. 

If someone who is familiar with the BOMs & POMs could take a quick review of https://github.com/jenkinsci/htmlpublisher-plugin/pull/57 just to make sure I'm not digging myself deeper into the ditch that would be most appreciated :)

Thanks
Richard.
 

Slide

unread,
May 4, 2020, 8:59:04 PM5/4/20
to jenkin...@googlegroups.com
On Mon, May 4, 2020 at 5:53 PM Richard Bywater <ric...@bywater.nz> wrote:
On Tue, 5 May 2020 at 01:01, Jesse Glick <jgl...@cloudbees.com> wrote:
> I've got the build to work again by removing recommendedConfigurations and switching to explicitly building the minimum version of Jenkins that is referenced in the pom.xml

This makes no sense. If you _only_ want to build the version
referenced in `pom.xml`, just

buildPlugin()

The point of `configurations` is to build against _newer_ versions as well.

Thanks - I didn't realise that. After reading the README https://github.com/jenkins-infra/pipeline-library I wasn't clear on what the default behaviour was if you didn't specify any of the optional arguments. I'm also confused by the statement "Gradle support in buildPlugin() is deprecated and will be eventually removed. Please use buildPluginWithGradle()". Is that actually accurate? Should we be using Gradle builds by default now?
 

This just means that if you use Gradle to build your plugin, you should not be using buildPlugin() anymore, you should use buildPluginWithGradle() instead. Maven builds are still the normal and most supported method for building Jenkins plugins.

--
Website: http://earl-of-code.com

Richard Bywater

unread,
May 4, 2020, 9:01:35 PM5/4/20
to jenkin...@googlegroups.com
Thanks. I totally somehow missed the "Gradle support in" part of that both when I read it the couple of times and when I pasted... Time for a break I think!

Richard.

--
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/CAPiUgVd%2BvoxjEASVCO30C9iobk2aDGp2fwZNWjvSj4P1X-uLyQ%40mail.gmail.com.

Oleg Nenashev

unread,
May 11, 2020, 3:05:34 PM5/11/20
to Jenkins Developers
We have reverted the recommendedConfigurations() patch for now.
Back to the drawing board, we still need to somehow ensure that recommended configurations can evolve without breaking instances.


On Tuesday, May 5, 2020 at 3:01:35 AM UTC+2, Richard Bywater wrote:
Thanks. I totally somehow missed the "Gradle support in" part of that both when I read it the couple of times and when I pasted... Time for a break I think!

Richard.

On Tue, 5 May 2020 at 12:59, Slide <slid...@gmail.com> wrote:


On Mon, May 4, 2020 at 5:53 PM Richard Bywater <ric...@bywater.nz> wrote:
On Tue, 5 May 2020 at 01:01, Jesse Glick <jgl...@cloudbees.com> wrote:
> I've got the build to work again by removing recommendedConfigurations and switching to explicitly building the minimum version of Jenkins that is referenced in the pom.xml

This makes no sense. If you _only_ want to build the version
referenced in `pom.xml`, just

buildPlugin()

The point of `configurations` is to build against _newer_ versions as well.

Thanks - I didn't realise that. After reading the README https://github.com/jenkins-infra/pipeline-library I wasn't clear on what the default behaviour was if you didn't specify any of the optional arguments. I'm also confused by the statement "Gradle support in buildPlugin() is deprecated and will be eventually removed. Please use buildPluginWithGradle()". Is that actually accurate? Should we be using Gradle builds by default now?
 

This just means that if you use Gradle to build your plugin, you should not be using buildPlugin() anymore, you should use buildPluginWithGradle() instead. Maven builds are still the normal and most supported method for building Jenkins plugins.

--

--
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.
Reply all
Reply to author
Forward
0 new messages