Can you add support for the Jenkins JUnit Plugin Report Tool?

[museadmin]

At the moment ossindex uses a graphics library - I think - to update the terminal window when running.

Jenkins however gives expects a normal scrolling output from tools that it runs, so the output when viewed in the console output page is not very helpful. It is also buried midway down the page showing all of the output from every stage in the pipeline.

Jenkins supports the JUnit plugin with gives a great view of the test results while organising the results with the failures grouped at the top of the page. It expects a simple XML format to drive the results page and is something of an industry standard.

Let me know if you'll consider it and if you require any help defining requirements etc.

In fact, if your up for giving me a few pointers on how the project is organised, I'd be interested in dusting off my Java and trying to code it myself...

[ken-duck]

Logging is currently done using SLF4J, though I don't currently know what the default logger implementation is that it is using.

I am definitely interested in exploring the export of data in a format acceptable by Jenkins. I have many things on the list at the moment, so if you are keen on giving it a go I can definitely send you some pointers on the code which should make it rather easy. I will put together a small document shortly that will hopefully tell you what you need (and if you are keen).

I am always interested in including other people's contributions.

If you would like to give it a shot, in order to directly use your contribution Sonatype requests that you sign a CLA (Contributor License Agreement) which more or less grants Sonatype permission to use the code. The agreement is reasonably short.

http://www.sonatype.org/SonatypeCLA.pdf

If you are alright with this, you can send the signed document here: jhesse@sonatype.com

If you could then notify me that would be great, since I will probably not be informed directly.

If you would rather not then I will definitely try and add this feature in when time permits.

[museadmin]

Hi Ken, Happy to sign the CLA but the link you provide doesn't actually go to a pdf... It takes me to https://my.sonatype.com/ for some reason. Yes I would enjoy the excuse to dust of my Java and make a contribution. Cheers Brad

[ken-duck]

Ha. I have spent some time looking around, and it appears that the website has undergone significant revision in the last week or so. I am procuring a copy of the CLA, or finding its new home. I will let you know when I have a copy available or when it has been republished to the site.

[MarkusAmshove]

I think the behaviour you get with Gradle was introduced in a update to Gradle (see 4.0 Release Notes)

Could you try to use gradle audit --console=plain in Jenkins and see how it looks like?

If it works you can set it in your global gradle.properties file on the buildserver like here.

But I agree that there needs some kind of reporting (like generating HTML and XML). Maybe there can be a shared format for OSSIndex and a Jenkins plugin in the future, that way the maven, msbuild, etc. clients could also use it

[museadmin]

Hi Ken :) No worries. Let me know when you have it. Hi Markus,

Sure I'll try that, but am also keen on utilising the reporting plugins available on Jenkins and this would be a good opportunity for me to dust off my Java developing. Have been using Ruby for a while and am currently caught up in doing security scanning for a project. So it would be nice to get back into it.

I think the JUnit plugin would be a popular choice for users who want this in their CI pipelines. So it would be good to do this while I have access to a Jenkins server.

[museadmin]

Hi Ken

Any luck finding that CLA?

[ken-duck]

They are still working on getting the CLA on the new site. I believe they are working on automating the whole process. In the meanwhile I was sent this copy of the CLA.

Please sign it and email the signed copy to jhesse@sonatype.com, then let me know (in case I don't hear from them automatically).

Thanks!

SonatypeCLA.pdf

[museadmin]

Hi Ken

Was off over easter so have just picked this up.

I have sent the signed CLA to the email address above

Brad

[museadmin]

Hi Ken,

I've pulled the project and tried running the unit tests but see this error that I don't understand:

`org.gradle.testkit.runner.InvalidPluginMetadataException: Test runtime classpath does not contain plugin metadata file 'plugin-under-test-metadata.properties'

at org.gradle.testkit.runner.internal.PluginUnderTestMetadataReading.readImplementationClasspath(PluginUnderTestMetadataReading.java:44)
at org.gradle.testkit.runner.internal.PluginUnderTestMetadataReading.readImplementationClasspath(PluginUnderTestMetadataReading.java:37)
at org.gradle.testkit.runner.internal.DefaultGradleRunner.withPluginClasspath(DefaultGradleRunner.java:146)
at net.ossindex.integrationtests.OssIndexAuditPluginTests.a project with no dependencies should not fail(OssIndexAuditPluginTests.groovy:30)

`

Is this a missing dependency?

Unfortunately, I might need a little nursemaiding to get up and running...

[museadmin]

Hi Ken

Beside the missing dependency, I could really do with some guidance on how you would normally refactor OSSIndex and run it in debug mode.

At the moment I am trying to figure out how to get my project to switch from resolving the production version of OSSIndex and pointing it at a local version instead, so I can work on it. Is that the approach you use?

[ken-duck]

Sorry for the delay. I will have some time today (Thursday) and will see what I can do to help. It has been a bit since I last ran so it might take a few minutes (I'm a Maven guy myself ;) )

[ken-duck]

FYI, I am not getting the "missing dependency" problem. I do get a failed test, but I have a sneaking suspicion that it may be because the data has changed underneath the tool. I will look into that.

The last feature I wrote (the proxy code) I cheated by writing unit tests (using mocks) that allowed me to avoid actually running the tool and focus specifically on the new functionality. I am not certain how hard that will be for your feature, but I suspect in your case we need to be able to run a dev version anyhow to properly test.

That being the case I will work on figuring out how to run a development version. Unfortunately not having experience with Gradle beyond running the build and test for this plugin I will be learning along the way. Together we shall find a way!

[ken-duck]

Ooh, you know what. At the very least we can write a new groovy test class like the first one (once we get them working for you). That will be able to exercise your new code. So the goal is to get the tests working on your machine.

So...

Run gradle -version and post your results. Here are mine for comparison:

> gradle -version

------------------------------------------------------------
Gradle 4.6
------------------------------------------------------------

Build time:   2018-02-28 13:36:36 UTC
Revision:     8fa6ce7945b640e6168488e4417f9bb96e4ab46c

Groovy:       2.4.12
Ant:          Apache Ant(TM) version 1.9.9 compiled on February 2 2017
JVM:          1.8.0_144 (Oracle Corporation 25.144-b01)
OS:           Mac OS X 10.13.3 x86_64

When you are trying to run the tests, are you running from the command line or from an IDE? I found something that may help if you are running in "IDEA": https://stackoverflow.com/questions/44679007/plugin-under-test-metadata-properties-not-created-by-gradle-testkit-when-running

[museadmin]

Thanks Ken,

I fooled around with rebuilding the project and eventually arrived at a point where the tests run and I no longer see the missing dependency issue. Now I also have one failing test. So looks like we're starting from the same place at last!

The failing test is - "a project which ignores a specific artifact but has another vulnerability should fail"

My gradle version:

Gradle 4.6
------------------------------------------------------------

Build time:   2018-02-28 13:36:36 UTC
Revision:     8fa6ce7945b640e6168488e4417f9bb96e4ab46c

Groovy:       2.4.12
Ant:          Apache Ant(TM) version 1.9.9 compiled on February 2 2017
JVM:          1.8.0_121 (Oracle Corporation 25.121-b13)
OS:           Mac OS X 10.13.4 x86_64

Yes, unfortunately I am more familiar with Maven than gradle as well, so we'll have to fumble our way to a conclusion as best we can. I would like to get away with not learning a lot about gradle in order to implement this change :)

In the project where I am running ossindex at the moment the settings in build.gradle are:

    apply plugin: 'net.ossindex.audit'

    audit {
        failOnError = false
        ignore = [ 'ch.qos.logback:logback-core',
                   'org.springframework.security:spring-security-core',
                   'com.sun.mail:javax.mail:1.5.2' ]
    }

and that's pretty much it. They fall within the configuration - allprojects {}

My intention was to try to change the location of the plugin to point to the local ossindex project. The idea being to try to eventually run it locally in debug mode in IntelliJ.

I got a bit lost trying to set that up. I suspect that the answer is to add the jar to the classpath as a file reference. I was struggling with that, probably because that missing dependency error was preventing an actual build of the jar.

I've commented out the failing test and recompiled the project and things are looking green, so I'll try again. Will let you know how I get on.

[museadmin]

Well, having some success...

In the project under test:

Commented out the existing classpath entry:

classpath "gradle.plugin.net.ossindex:ossindex-gradle-plugin:0.1.1"

and added:

classpath files('/Users/bradley/ossindex-gradle-plugin/build/libs/ossindex-gradle-plugin-0.1.2-SNAPSHOT.jar')

And applied it with:

apply plugin: 'net.ossindex.audit'

    audit {
        failOnError = false
        ignore = [ 'ch.qos.logback:logback-core',
                   'org.springframework.security:spring-security-core',
                   'com.sun.mail:javax.mail:1.5.2'
        ]
    }

In the ossindex project on branch proxy-support2:

In OssIndexPlugin.java in the apply() method I added:

System.out.println("Local Version of OSSIndex");

Now if I run

./gradlew tasks

I see the string "Local Version of OSSIndex" printed out onscreen. So I'm confident that I'm now hitting my local version.

Issues:

the problem now is that if I run:

./gradlew audit

I see this error message after my debug string:

FAILURE: Build failed with an exception.

    * What went wrong:
    Execution failed for task ':audit'.
    > net/ossindex/common/OssIndexApi

This is presumably failing when the project imports:

import net.ossindex.common.OssIndexApi;

in DependencyAuditor.java

I'm wondering if this is an issue with the branch itself...

I'll try running in debug mode next and see if I can get that working. If so I can maybe step into the issue and see what's going on.

[ken-duck]

I'm bringing my local up to sync with where you are at. Meanwhile I pushed some code into master so you will want to re-fetch master to ensure we are even with each other. One of the changes is the version number has changed, so it is now 0.2.0-SNAPSHOT

[ken-duck]

Beauty. I duplicated your results, so I have now caught up with you :)

[ken-duck]

OK, the issue is that the JAR we are building locally does not contain the dependencies. We need a "fat" jar built. I am working on a solution now.

[museadmin]

Cool, that's great.

I'm working from home tomorrow and so should be able to devote the whole day to this. Do you think it would be better to exchange emails rather than communicate via this page? If so you can contact me on bradley.atkins at bjss.com

I don't know if it will be possible to run in debug mode from the project under test. I can run the audit task in debug mode from there, but I don't hit break points in the plugin project. I guess this is because were running against the built jar at that point? So unless you can find a way to do it, I guess I'll have to rely on writing out debug statements as I go along.

Will pull master in the morning as you suggest. Let me know if I need to pull again to get your fat jar stuff.

[ken-duck]

Bam! If you pull the newest version there is now a shadowJar task that builds a JAR file which contains all of the dependencies.

gradle shadowJar

Will create the following jar:

> ls build/libs/
ossindex-gradle-plugin-0.2.0-SNAPSHOT-all.jar
...

I'll continue discussions via email.

[ken-duck]

Closing, as this was added (by you!) a long time ago and apparently I forgot to close the issue back then :D