findsecbugs in spotbugs

[Jeff Thompson]

Jenkins developers,

I've been working on introducing findsecbugs into the Jenkins developer
ecosystem. findsecbugs is a plugin for spotbugs (formerly findbugs) that
adds analysis for a significant collection of bug rules that could
potentially impact security. More information is at
https://find-sec-bugs.github.io/

I've got PRs about ready for merge to introduce findsecbugs into Jenkins
( https://github.com/jenkinsci/jenkins/pull/4381 ) and Remoting (
https://github.com/jenkinsci/remoting/pull/361 ).

The problem with introducing a tool like this in any legacy software is
that it finds things that could have been better implemented or are
outdated but are not real issues. Turning it on means going through the
all the findings, analyzing them, and then suppressing them (hopefully
individually) or fixing them. I've done that in my two PRs.

I've also gone through this with a sampling of 7 plugins. Only one of
them didn't detect any findings, but they didn't necessarily have any
real security issues. I intend to push PRs for these plugins I've tried
in the coming days.

I believe there is a lot of value in having this tool detect new,
potential issues as we move forward with changes and new code. I've been
glad in the past at how spotbugs and other tools help catch things
before PRs are merged.

I want to get findsecbugs turned on in the parent plugin pom.
@StefanSpieker also has a PR to turn it on in the parent Jenkins pom.

I'm not sure whether we need to be more cautious about turning
findsecbugs on in the parent poms. Do we need to make it opt-in? How do
we encourage people to opt-in? Or, does that just become something
everyone has to do to move forward to latest poms? At a minimum I think
we should use @StefanSpieker's PR to turn it on in the Jenkins parent pom.

Jeff Thompson

[Raihaan Shouhell]

Hey Jeff,

I think it is ok to introduce it. Sounds like it would add value.
There should be a switch to at least disable failing the build because of findsecbugs.

Despite the potential problems with introducing it, I am +1 on it since it will definitely help the development of new plugins.

Like you said spotbugs has actually helped find a ton of bugs, I even find myself getting annoyed when the relevant annotation was missing that could potentially avoid a bug.

If this tool can help us avoid security issues the same way spotbugs helps with bugs that would be awesome.

Cheers,

Raihaan

[James Nord]

I had a quick peek at the 2 PRs and my main concern is that this found no security issues and forced annotations on a lot of places, that is it found no issues according to the PRs.

Whilst it could prevent issues being introduced in the future I am concerned it will cause 99% `@SuppressFBWarning` annoyance and not find the security issue.

The suppressions are also overly broad - for example https://github.com/jenkinsci/jenkins/pull/4381/files#diff-6b2c22336dd63b20019b8558c7e9a13fR599-R601  is completely incorrect.  This code can not make assumptions about the callers - only the caller of that method can make it and as such the Annotation needs to be on those methods not the utility method.

in other words I think if this just causes pain by having to add suppress warnings then I think it would be a bad thing.  I would be happy to see it catch the first real issue - but if that does not happen in a long time I think we should be prepared to back this out.  

my 2c.

[Jeff Thompson]

James,

You make valid points. Many of them, though, represent the nature of spotbugs, how it works, and particularly the difficulties of adding anything like it to legacy code. The problem just becomes perpetual -- the only good time to ever add these kinds of checks is in the past, there is a hurdle to adding them and dealing with them at any current or future point, which tends to result in overly broad suppressions, and so it's easy to just keep putting it off. Once added, these checks provide value: they make it harder to introduce new problems (of the types checked) and they point out areas of technical debt that can be improved.

In rough terms, I see the following approaches:

1) Make no changes. Continuing as we are just keeps us ignorant of the potential issues. With regular issues this may just mean there is a defect that needs to be fixed. With findsecbugs, it may be an exploitable security bug. Our ignorance doesn't protect us.

2) Something along the lines of my proposals: Enable it at the current spotbugs level, examine the individual findings, and suppress or act individually. As you note, this does lead to a lot of individual @SuppressFBWarning lines.

3) Enable it but don't suppress (nearly) anything. This requires (almost) all findings to be "corrected" before it's enabled for new development. Since we would be making sure not to suppress unless absolutely necessary we would need to first fix bad coding practice that doesn't result in usage issues. With legacy code, particularly on the scale of Jenkins, this practically becomes approach #1 because the barrier to ever doing it becomes too high.

4) Enable it but suppress via the exclude file rather than embedded @SuppressFBWarning lines. This tends to lead people to suppress by bug or category rather than examining the individual findings. If used more precisely, it disconnects the finding from the code, making it more difficult to eventually correct the technical debt.

My experiments with findsecbugs have found some areas of real concern. There's one I can readily share publicly at this time to illustrate. As I was analyzing one findsecbugs finding, I immediately recognized it as SECURITY-1322 / CVE-2019-10320, which was fixed in the 2019-05-21 advisory. The scanner found it in the master branch, because we left part of the code in to facilitate migration. (It's essentially impossible to create new configurations with the problem.) The combination of the @Deprecated and @SuppressFBWarning annotations highlight that it should be fully removed some day. If someone had run findsecbugs a year ago it would have caught that as a real vulnerability.

My experience with spotbugs is that it can be a hassle at times, but it tends to encourage cleaner code and sometimes it finds real concerns.

I don't know how we could ever get around to enabling new rules except with something along the lines of my proposal, #2. I hope we can proceed with it, even if imperfectly.

Jeff

--
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/b1fde6e8-38df-4c4c-9da5-fbf616c2c099%40googlegroups.com.

[Jesse Glick]

On Wed, Dec 11, 2019 at 2:06 PM Jeff Thompson <jtho...@cloudbees.com> wrote:
> As I was analyzing one findsecbugs finding, I immediately recognized it as SECURITY-1322 […]

> If someone had run findsecbugs a year ago it would have caught that as a real vulnerability.

You are referring to

https://github.com/jenkinsci/credentials-plugin/commit/40d0b5cc53c265b601ffaa4469310fad390a80fb

I guess? If it managed to catch that, then this alone seems to justify
turning it on. My concern was that the idiosyncratic architecture of
Jenkins would make it hard for a generic security scanner to find
relevant issues.

I agree that the only maintainable usage mode is to examine individual
lines of code and either rewrite them or add `@SuppressFBWarning`. It
can be tedious, but it is compatible with code review and incremental
improvements.

One thing I do wish for (not limited to security issues): that
SpotBugs could be asked to report a warning (or error?) if you have an
annotation in the code which would _not_ be required in its current
scanner configuration. Sometimes people just drop an annotation onto
some 100-line method asking it to ignore an apparent NPE or
synchronization mismatch or whatever, the code is subsequently
refactored, and then no one ever thinks to go back and verify that the
annotation is still necessary. IDEs and style checkers can flag unused
imports or private methods; this would be in the same mold.

[Jeff Thompson]

On 12/12/19 7:10 AM, Jesse Glick wrote:

On Wed, Dec 11, 2019 at 2:06 PM Jeff Thompson <jtho...@cloudbees.com> wrote:

As I was analyzing one findsecbugs finding, I immediately recognized it as SECURITY-1322 […]
If someone had run findsecbugs a year ago it would have caught that as a real vulnerability.

You are referring to

https://github.com/jenkinsci/credentials-plugin/commit/40d0b5cc53c265b601ffaa4469310fad390a80fb

I guess? If it managed to catch that, then this alone seems to justify
turning it on. My concern was that the idiosyncratic architecture of
Jenkins would make it hard for a generic security scanner to find
relevant issues.

Yes, that's the one.

Findsecbugs is clearly biased to web applications, which makes it fairly applicable to Jenkins. Some things it reports on the agent side of Remoting would be important on a server. Remoting operates on both sides so it requires consideration as to how or where each piece runs. There are some findsecbugs rules (at least 1) that just aren't treated as a concern in Jenkins. As I've been analyzing findings I've thought it would be cool to have some Jenkins-specific rules for findsecbugs, spotbugs, or some other tool to catch some of those idiosyncratic things. But, there's enough value in the rules it does have to catch common things. We should move forward on these ones because they're useful and maybe someday we can introduce some Jenkins-specific checks somewhere.

One thing I do wish for (not limited to security issues): that
SpotBugs could be asked to report a warning (or error?) if you have an
annotation in the code which would _not_ be required in its current
scanner configuration. Sometimes people just drop an annotation onto
some 100-line method asking it to ignore an apparent NPE or
synchronization mismatch or whatever, the code is subsequently
refactored, and then no one ever thinks to go back and verify that the
annotation is still necessary. IDEs and style checkers can flag unused
imports or private methods; this would be in the same mold.

+10

This would be fantastic. Sometimes I remove a suppress annotation and see if it's still necessary -- often it isn't. Going through these analyses I found a number of cases where an existing annotation was no longer necessary. It would be great to have this capability, but I'm not motivated enough to contribute this to spotbugs.

Jeff

[James Nord]

We now have the ability to actually put the suppressions at a finer level than just the method for many issues.  If we started to consiously do that it would be clearer when some things can be removed.

[Ullrich Hafner]

If it helps to prevent some errors I think it would make sense to enable it for plugins as well (in the parent pom). Can the execution of this additional plugin be removed in a specific plugin pom afterwards? I’m not sure how maven handles it.

I enabled the checker in my plugins and needed to disable it for tests as there where too many false positives have been reported:

<Match>
  <Bug category="SECURITY"/>
  <Class name="~.*Test.*" />
</Match>

 Additionally, I deactivated the following rules that seem to produce too many false positives:

<Match>
  <Bug pattern="DESERIALIZATION_GADGET, FORMAT_STRING_MANIPULATION, PATH_TRAVERSAL_IN, WEAK_FILENAMEUTILS"/>
</Match>

Maybe it makes sense to gather feedback from some other plugins as well before changing the parent pom.

--
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/54b09ff3-0494-4e30-8b32-b50cf144e654%40googlegroups.com.

[Jeff Thompson]

Yes, my goal is to also enable findsecbugs in the plugin parent pom. I think it's well worth it, just as regular spotbugs provides valuable findings in a number of cases.

I've currently got PRs awaiting review and approval for jenkins and remoting. I've got one approval for remoting so I'll proceed to merge that in before long.

I've also prepared branches for about half a dozen plugins where I've added it into their local configuration. I have planned on pushing those soon.

My idea is to prove it out with a selected set of projects and then work to roll it out more widely. I'm not sure how we want to proceed with adding it into the plugin parent pom. I'd like to just make it a standard part, but I think we might need to make it opt-in, such as with a profile, at least for an introductory period.

Thanks for the response,

Jeff

[Jeff Thompson]

I'm circling back to this discussion here on the dev list. I've gotten findsecbugs integrated into several Jenkins projects, including Jenkins itself. I pushed draft PRs demonstrating what it will look like in a handful of plugins.

I put together information on my observation and recommendations for developers when they start working with findsecbugs. My blog post is at https://jenkins.io/blog/2020/03/02/findsecbugs/ and my Jenkins Online Meetup recording is available at https://youtu.be/fotttu20Mf4 .

Now we're ready to start pushing findsecbugs integration more widely, particularly into parent poms. StefanSpieker has had a PR for adding it into the Jenkins parent pom since November: https://github.com/jenkinsci/pom/pull/61 . It's time to get that moving forward.

Jeff

[James Nord]

I would rather this did not get merged until after the 4.0 release of pom and have left further comment in the pr about the lack of reasonable opt out.

[Jeff Thompson]

On 3/25/20 1:47 PM, James Nord wrote:

I would rather this did not get merged until after the 4.0 release of pom and have left further comment in the pr about the lack of reasonable opt out.

James, you're talking about the plugin parent pom, right? The current PR is for the Jenkins pom, which is currently at 1.55-SNAPSHOT.

Any idea when we'll move forward to the 4.0 release of the plugin pom?

Jeff

[James Nord]

> James, you're talking about the plugin parent pom, right? The current PR is for the Jenkins pom, which is currently at 1.55-SNAPSHOT.

yes you are completely correct, my apologies.

[James Nord]

Hi Oleg et al.

is it time to move the plugin parent out of beta?

have not seen any negative feedback (or positive door that matter) but I've been using it for numerous proprietary plugins with no issue.

/James

[Tim Jacomb]

I've been using it on a few plugins, no issues

--
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/5d4104be-2fbc-428f-8992-91b11e41344b%40googlegroups.com.

[Jeff Thompson]

+1

I don't remember if I've pushed any commits that use the beta parent, but I've tried it out on a variety of different plugins I've investigated. I've found it to work better than any of the other earlier versions and can't think of any issues I've encountered.

Jeff

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

[Mark Waite]

I applied 4.0-beta-6 to the git client plugin as part preparation to set Jenkins 2.204.1 as the new required minimum version.  Worked great.  No issues detected.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/545f5189-e38e-2147-d166-e6f8933916e4%40cloudbees.com.

[Oleg Nenashev]

Hi all,

There was no new breaking changes coming in, and I think it is time to go ahead and release a 4.0 version.

I plan to do so tomorrow if there is no negative feedback.

It would be great if somebody could write a blogpost with a summary of the changes in the new major release

P.S: 4.0 works great in plugins I tried.

Best regards,

Oleg

On Monday, March 30, 2020 at 12:26:54 AM UTC+2, Mark Waite wrote:

I applied 4.0-beta-6 to the git client plugin as part preparation to set Jenkins 2.204.1 as the new required minimum version.  Worked great.  No issues detected.

On Thu, Mar 26, 2020 at 8:38 AM Jeff Thompson <jtho...@cloudbees.com> wrote:

+1

I don't remember if I've pushed any commits that use the beta parent, but I've tried it out on a variety of different plugins I've investigated. I've found it to work better than any of the other earlier versions and can't think of any issues I've encountered.

Jeff

On 3/26/20 3:20 AM, Tim Jacomb wrote:

I've been using it on a few plugins, no issues

On Thu, 26 Mar 2020 at 09:11, James Nord <james...@gmail.com> wrote:

Hi Oleg et al.

is it time to move the plugin parent out of beta?

have not seen any negative feedback (or positive door that matter) but I've been using it for numerous proprietary plugins with no issue.

/James

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

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/5d4104be-2fbc-428f-8992-91b11e41344b%40googlegroups.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.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BifrNfcECRgZ7A2fxros_vT1S0AezDr6C5HGFGPMgormdQ%40mail.gmail.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.

[Tim Jacomb]

This seems not to have happened, I'm happy to do it Oleg if you're too busy?

Thanks

Tim

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/dbeebe3e-d25e-44be-af92-1f26ce1c8582%40googlegroups.com.

[Tim Jacomb]

Hi

plugin pom 4 is now released,

Full release notes including all beta versions:

https://github.com/jenkinsci/plugin-pom/releases/tag/plugin-4.0

Thanks

Tim

[James Nord]

many thanks Tim

/James

[Ullrich Hafner]

I updated all my plugins now, everything is looking good! 

Only problem: I needed to switch the minimum baseline to 2.204.4. I tried 2.190.4 but got a lot of errors. I’m not sure if this BOM version is expected to work as well.

What I do not understand yet: do I still need to set the profile -Duse-jenkins-bom?

Seems that everything works correctly without that...

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3Bid6JLdKZiPOaZA5faNKp4zBAH0rS-jk2gzyxSgY%2BS9OtA%40mail.gmail.com.

[Oleg Nenashev]

Thanks James and Tim for the release! It is great to see it to be finally released. I updated the changelog a bit to make it shorter for duplicated dependencies and so on.

Hopefully it will improve developer experience for plugin maintainers.

What I do not understand yet: do I still need to set the profile -Duse-jenkins-bom?

 

No, it is included by default. Added a changelog entry 

Best regards,

Oleg Nenashev

On Monday, April 20, 2020 at 11:37:22 AM UTC+2, Ullrich Hafner wrote:

I updated all my plugins now, everything is looking good! 

Only problem: I needed to switch the minimum baseline to 2.204.4. I tried 2.190.4 but got a lot of errors. I’m not sure if this BOM version is expected to work as well.

What I do not understand yet: do I still need to set the profile -Duse-jenkins-bom?

Seems that everything works correctly without that...

Am 16.04.2020 um 21:38 schrieb Tim Jacomb <timja...@gmail.com>:

Hi

plugin pom 4 is now released,

Full release notes including all beta versions:

https://github.com/jenkinsci/plugin-pom/releases/tag/plugin-4.0

Thanks

Tim

On Wed, 15 Apr 2020 at 19:52, Tim Jacomb <timja...@gmail.com> wrote:

This seems not to have happened, I'm happy to do it Oleg if you're too busy?

Thanks

Tim

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/dbeebe3e-d25e-44be-af92-1f26ce1c8582%40googlegroups.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.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3Bid6JLdKZiPOaZA5faNKp4zBAH0rS-jk2gzyxSgY%2BS9OtA%40mail.gmail.com.

[Ullrich Hafner]

Seems there is a problem (but this is probably more related to the Jenkins baseline update to Jenkins 2.204.4): one of my integration tests fails now with:

A JavaScript exception occured at: HtmlPage(http://localhost:50637/jenkins/job/test0/configure)@768414821

======= EXCEPTION START ========

EcmaError: lineNumber=[1382] column=[0] lineSource=[null] name=[TypeError] sourceName=[http://localhost:50637/jenkins/static/f2d8818a/scripts/hudson-behavior.js] message=[TypeError: Cannot call method "hasClassName" of undefined (http://localhost:50637/jenkins/static/f2d8818a/scripts/hudson-behavior.js#1382)]

com.gargoylesoftware.htmlunit.ScriptException: TypeError: Cannot call method "hasClassName" of undefined (http://localhost:50637/jenkins/static/f2d8818a/scripts/hudson-behavior.js#1382)

        at com.gargoylesoftware.htmlunit.javascript.JavaScriptEngine$HtmlUnitContextAction.run(JavaScriptEngine.java:883)

        at net.sourceforge.htmlunit.corejs.javascript.Context.call(Context.java:617)

        at net.sourceforge.htmlunit.corejs.javascript.ContextFactory.call(ContextFactory.java:534)

        at com.gargoylesoftware.htmlunit.javascript.HtmlUnitContextFactory.callSecured(HtmlUnitContextFactory.java:336)

        at com.gargoylesoftware.htmlunit.javascript.JavaScriptEngine.callFunction(JavaScriptEngine.java:812)

        at com.gargoylesoftware.htmlunit.javascript.JavaScriptEngine.callFunction(JavaScriptEngine.java:784)

        at com.gargoylesoftware.htmlunit.html.HtmlPage.executeJavaScriptFunction(HtmlPage.java:2542)

        at com.gargoylesoftware.htmlunit.html.HtmlPage.executeJavaScriptFunction(HtmlPage.java:2535)

        at com.gargoylesoftware.htmlunit.javascript.host.event.EventListenersContainer.executeEventListeners(EventListenersContainer.java:342)

        at com.gargoylesoftware.htmlunit.javasc

Is this is a known problem when using HtmlUnit tests with Jenkins 2.204.4? 

[Matt Sicker]

One of the main backward-incompatible changes in pom 4.x is the
HtmlUnit upgrade, so I'd guess that you've discovered one of said
incompatibilities.

> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/E0F9EF7A-BF9D-465A-B3E9-FC1548AFD42C%40gmail.com.



--
Matt Sicker
Senior Software Engineer, CloudBees

[Ullrich Hafner]

After updating HtmlUnit to 2.39.0 the problem still appears:. I think the error actually is somewhere else, when I open the config page I get:

/jenkins-core/2.204.4/jenkins-core-2.204.4.jar!/lib/form/optionalBlock.jelly:80:23: &lt;d:invokeBody&gt; jar:file:/Users/hafner/.m2/repository/org/jenkins-ci/main/jenkins-core/2.204.4/jenkins-core-2.204.4.jar!/jenkins/model/OptionalJobProperty/config.jelly:30:97: &lt;st:include&gt; This tag does not understand the 'class‘ attribute

Is this a core problem or is this just an incompatibility in one of the plugins I am loading in my integration test?

> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAEot4owvW%3DcASvVoMWPyRhdjYcJRfh_Uh25fF%3Dx%3DbgppW2xVBw%40mail.gmail.com.

[Jesse Glick]

On Mon, Apr 20, 2020 at 12:41 PM Ullrich Hafner
<ullrich...@gmail.com> wrote:
> Is this a core problem or is this just an incompatibility in one of the plugins I am loading in my integration test?

Offhand smells like an incompatibility between one of your plugins and
a newer core version.

[Ullrich Hafner]

Ok, I found the problem: maven-enforcer considered harmful. I don’t know how many hours I already spent fixing maven-enforcer library problems. The enforcer never found a real bug up to know, it is causing only confusion and so many lost hours of my valuable coding time :-( 

The problem was the following dependency (from Jenkins 2.204.4) that I needed to add in the dependency configuration section of the POM to get the enforcer quite:

<commons.beanutils.version>1.9.4</commons.beanutils.version>

<dependency>
  <groupId>commons-beanutils</groupId>
  <artifactId>commons-beanutils</artifactId>
  <version>${commons.beanutils.version}</version>
</dependency>

After ignoring this library in the enforcer everything is green again...

--
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/CANfRfr1DHp_8zRpaFAtFd4a6FjVBZLLdeerhZ3cNpDAjMS7arQ%40mail.gmail.com.

[Jesse Glick]

On Mon, Apr 20, 2020 at 6:11 PM Ullrich Hafner <ullrich...@gmail.com> wrote:
> The enforcer never found a real bug up to now

Interesting, before using `RequireUpperBoundDeps` I had on numerous
occasions wasted plenty of time trying to track down cryptic
`LinkageError`s caused by mismatched dependencies.

[James Nord]

my experience is the same as Ulli.
never had an issue with linkage or class not found, and spend a lot of time fixing upper bounds to keep the enforcer rule happy (probably wrongly but if it keeps it happy....)
(hence the introduction of the jenkins BOM)

[James Nord]

> What I do not understand yet: do I still need to set the profile -Duse-jenkins-bom

no. is that still documented somewhere? if so I need to remove it

[Ullrich Hafner]

I think Tim fixed that already yesterday (https://github.com/jenkins-infra/jenkins.io/commit/fdfec966fcc6048cfd2703ec2baded40eddd1db8)

Am 22.04.2020 um 00:26 schrieb James Nord <james...@gmail.com>:

-Duse-jenkins-bom

[Ullrich Hafner]

Was that while developing plugins or core? I think when checking dependencies in core you have the same set of components during maven compile and in runtime. But when compiling a plugin you almost never have the same dependencies during compile and runtime. So even if the enforcer finds something during compile it might be totally different when deployed to a real Jenkins system.

[Ullrich Hafner]

> Am 22.04.2020 um 00:25 schrieb James Nord <james...@gmail.com>:
>
> (hence the introduction of the jenkins BOM)
>

This is really a big help in plugin development, thank you all for your work!

[Jesse Glick]

On Wed, Apr 22, 2020 at 4:41 AM Ullrich Hafner <ullrich...@gmail.com> wrote:
>> occasions wasted plenty of time trying to track down cryptic `LinkageError`s caused by mismatched dependencies.
>
> Was that while developing plugins or core?

Plugins.

> even if the enforcer finds something during compile it might be totally different when deployed to a real Jenkins system.

I was referring more to errors in tests. As noted in JENKINS-41827,
some class loading scenarios can work in tests and break in production
or vice-versa.

[Gavin Mogan]

Are there version limits to the parent pom now? Is there a way to disable the bom stuff for older jenkins?

https://ci.jenkins.io/blue/organizations/jenkins/Plugins%2Fgraphql-server-plugin/detail/dependabot%2Fmaven%2Forg.jenkins-ci.plugins-plugin-4.1/1/pipeline/

Caused by: org.eclipse.aether.transfer.ArtifactNotFoundException: Could not find artifact org.jenkins-ci.main:jenkins-bom:pom:2.150.1 in incrementals (https://repo.jenkins-ci.org/incrementals/)

 

--
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/CANfRfr0DFXCo1HH8xg2WfWfSAjM%3D2-U839%3D9365bw5Kxsu8%3DQQ%40mail.gmail.com.

[Oleg Nenashev]

There is a "Note: Jenkins 2.164.x is the minimum supported version as it's the first version that includes the Jenkins bom" warning in release notes https://github.com/jenkinsci/plugin-pom/releases/tag/plugin-4.0

For older core versions we can still release the 3.x Plugin POM versions on-demand.

Best regards,

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/exd3fc9NUAg/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_DuuNqxatsTiNXbrNpxnE%2B_mHZjwqxu9i3Qu5bTHhSP0Jig%40mail.gmail.com.

[Gavin Mogan]

Oh, i think my eyes automatically glaze over the start of these things after looking at recipe sites. That or italics. My bad, I'll update to 2.164, or tell dependabot to ignore this dep.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLDE2fwANgoBk5dGBW%2BA0Mq0GDdOPraziNtFoc%2BT2uC1GA%40mail.gmail.com.

[Ullrich Hafner]

Am 23.04.2020 um 01:06 schrieb 'Gavin Mogan' via Jenkins Developers <jenkin...@googlegroups.com>:

 I'll update to 2.164, or tell dependabot to ignore this dep.

I think you need to update to at 2.204 (I got errors for older versions). But it is also safe to ignore the plugin pom 4.x updates.  

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_DusvB1sDb3wSwHFV2RK6JZKZsPAfTmcth18c%2Bh%2BCAn5Sgg%40mail.gmail.com.

[Tim Jacomb]

2.164.x is fine, the bom sample plugin is using it on this version 

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/25823FF0-3E4A-41D1-A6DD-E98989E27F97%40gmail.com.