[JIRA] (JENKINS-56580) Configuration for JaCoCo plugin doesn't generate source inclusions
Title: Message Title
cristalp commented on JENKINS-56580
Re: Configuration for JaCoCo plugin doesn't generate source inclusions
Well, I can't see it on https://jenkinsci.github.io/job-dsl-plugin/#path/mavenJob-publishers-jacocoCodeCoverage When I try to use it with
jacocoCodeCoverage {
execPattern("**/${project}/**/target/**.exec")
inclusionPattern("**/*.class")
exclusionPattern("**/*Test*.class")
classPattern("**/${project}/**/target/classes")
sourcePattern("**/${project}/**/src/main/java")
sourceInclusionPattern('**/*.java')
}
I get
No signature of method: javaposse.jobdsl.dsl.helpers.publisher.JacocoContext.sourceInclusionPattern() is applicable for argument types: (java.lang.String) values: [**/*.java]
Add Comment
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-56737) Java compiler warnings parser can't cope with Maven timestamps in log
Title: Message Title cristalp commented on JENKINS-56737 Re: Java compiler warnings parser can't cope with Maven timestamps in log Thanks, guys! Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-56737) Java compiler warnings parser can't cope with Maven timestamps in log
Title: Message Title cristalp created an issue Jenkins / JENKINS-56737 Java compiler warnings parser can't cope with Maven timestamps in log Issue Type: Bug Assignee: Ulli Hafner Components: analysis-model-api-plugin Created: 2019-03-25 10:04 Priority: Minor Reporter: cristalp We switched on Maven timestamps in our log, since it's a handy way to check build times. In Maven, this is done by editing conf/logging/simplelogger.properties and setting org.slf4j.simpleLogger.showDateTime=true This results in compiler warnings like this: 08:52:34.395 [WARNING] /my/path/to/workspace/src/main/java/my/package/TemporalJsonSeqFiling.java:[86,76] redundant cast to long ( given that the date/time format is org.slf4j.simpleLogger.dateTimeFormat=HH:mm:ss.SSS ) Taking a look at the source code, it seems that JAVAC_WARNING_PATTERN does a full match of the line, which does not accept that something could exist before [WARNING] . We use other parsers for Checkstyle, PMD etc. and they work fine.
[JIRA] (JENKINS-56580) Configuration for JaCoCo plugin doesn't generate source inclusions
Title: Message Title
cristalp updated an issue
Jenkins / JENKINS-56580
Configuration for JaCoCo plugin doesn't generate source inclusions
Change By:
cristalp
I configure the JaCoCo plugin by hand, trying to be as specific as possible: The paths are all configured for my project ({{wdl-util}}).In the GUI, I can see {{Inclusions (e.g.: **/*.java,**/*.groovy,**/*.gs)}}, which translates to the following in {{config.xml}} :{code:xml} **/wdl-util/**/target/**.exec **/wdl-util/**/target/classes **/wdl-util/**/src/main/java **/*.java**/*.class **/*Test*.class ...{code}When I run the job, this is what I see:{code}[JaCoCo plugin] Collecting JaCoCo coverage data...[JaCoCo plugin] **/wdl-util/**/target/**.exec;**/wdl-util/**/target/classes;**/wdl-util/**/src/main/java; locations are configured[JaCoCo plugin] Number of found exec files for pattern **/wdl-util/**/target/**.exec: 1[JaCoCo plugin] Saving matched execfiles: /ige/jenkins/work/jobs/wdl-util/workspace/wdl-util/target/jacoco.exec[JaCoCo plugin] Saving matched class directories for class-pattern: **/wdl-util/**/target/classes: [JaCoCo plugin] - /ige/jenkins/work/jobs/wdl-util/workspace/wdl-util/target/classes 26 files[JaCoCo plugin] Saving matched source directories for source-pattern: **/wdl-util/**/src/main/java: [JaCoCo plugin] Source Inclusions: **/*.java[JaCoCo plugin] Source Exclusions: [JaCoCo plugin] - /ige/jenkins/work/jobs/wdl-util/workspace/wdl-util/src/main/java 32 files[JaCoCo plugin] Loading inclusions files..[JaCoCo plugin] inclusions: [**/*.class][JaCoCo plugin] exclusions: [**/*Test*.class][JaCoCo plugin] Thresholds: JacocoHealthReportThresholds [minClass=0, maxClass=0, minMethod=0, maxMethod=0, minLine=0, maxLine=0, minBranch=0, maxBranch=0, minInstruction=0, maxInstruction=0, minComplexity=0, maxComplexity=0][JaCoCo plugin] Publishing the results..[JaCoCo plugin] Loading packages..[JaCoCo plugin] Done.[JaCoCo plugin] Overall coverage: class: 96, method: 88, line: 89, branch: 85, instruction: 89{code}Note the line with {{Source Inclusions}}.Apparently, this is a part that I can't generate with the Job DSL plugin, since this option (and a couple of others that I can find in {{config.xml}}) are missing.So, generating the job{code:groovy}publishers {jacocoCodeCoverage{ execPattern("**/${project}/**/target/**.exec") inclusionPattern("**/*.class") exclusionPattern("**/*Test*.class") classPattern("**/${project}/**/target/classes") sourcePattern("**/${project}/**/src/main/java")} }{code}results in the following {{config.xml}} :{code:xml}**/wdl-util/**/target/**.exec**/wdl-util/**/target/classes**/wdl-util/**/src/main/java**/*.class**/*Test*.class...{code}{{sourceInclusionPattern}} and {{sourceExclusionPattern}} are missing.When I open the job configuration, I can still see {{Inclusions (e.g.: **/*.java,**/*.groovy,**/*.gs)}} with a default v
[JIRA] (JENKINS-56580) Configuration for JaCoCo plugin doesn't generate source inclusions
Title: Message Title
cristalp updated an issue
Jenkins / JENKINS-56580
Configuration for JaCoCo plugin doesn't generate source inclusions
Change By:
cristalp
I configure the JaCoCo plugin by hand, trying to be as specific as possible: The paths are all configured for my project ({{wdl-util}}).In the GUI, I can see {{Inclusions (e.g.: **/*.java,**/*.groovy,**/*.gs)}}, which translates to the following in {{config.xml}} :{code:xml} **/wdl-util/**/target/**.exec **/wdl-util/**/target/classes **/wdl-util/**/src/main/java **/*.java**/*.class **/*Test*.class ...{code}When I run the job, this is what I see:{code}[JaCoCo plugin] Collecting JaCoCo coverage data...[JaCoCo plugin] **/wdl-util/**/target/**.exec;**/wdl-util/**/target/classes;**/wdl-util/**/src/main/java; locations are configured[JaCoCo plugin] Number of found exec files for pattern **/wdl-util/**/target/**.exec: 1[JaCoCo plugin] Saving matched execfiles: /ige/jenkins/work/jobs/wdl-util/workspace/wdl-util/target/jacoco.exec[JaCoCo plugin] Saving matched class directories for class-pattern: **/wdl-util/**/target/classes: [JaCoCo plugin] - /ige/jenkins/work/jobs/wdl-util/workspace/wdl-util/target/classes 26 files[JaCoCo plugin] Saving matched source directories for source-pattern: **/wdl-util/**/src/main/java: [JaCoCo plugin] Source Inclusions: **/*.java[JaCoCo plugin] Source Exclusions: [JaCoCo plugin] - /ige/jenkins/work/jobs/wdl-util/workspace/wdl-util/src/main/java 32 files[JaCoCo plugin] Loading inclusions files..[JaCoCo plugin] inclusions: [**/*.class][JaCoCo plugin] exclusions: [**/*Test*.class][JaCoCo plugin] Thresholds: JacocoHealthReportThresholds [minClass=0, maxClass=0, minMethod=0, maxMethod=0, minLine=0, maxLine=0, minBranch=0, maxBranch=0, minInstruction=0, maxInstruction=0, minComplexity=0, maxComplexity=0][JaCoCo plugin] Publishing the results..[JaCoCo plugin] Loading packages..[JaCoCo plugin] Done.[JaCoCo plugin] Overall coverage: class: 96, method: 88, line: 89, branch: 85, instruction: 89{code}Note the line with {{Source Inclusions}}.Apparently, this is a part that I can't generate with the Job DSL plugin, since this option (and a couple of others that I can find in {{config.xml}}) are missing.So, generating the job{code:groovy}publishers {jacocoCodeCoverage{ execPattern("**/${project}/**/target/**.exec") inclusionPattern("**/*.class") exclusionPattern("**/*Test*.class") classPattern("**/${project}/**/target/classes") sourcePattern("**/${project}/**/src/main/java")} }{code}results in the following {{config.xml}} :{code:xml}**/wdl-util/**/target/**.exec**/wdl-util/**/target/classes**/wdl-util/**/src/main/java**/*.class**/*Test*.class...{code}{{sourceInclusionPattern}} and {{sourceExclusionPattern}} are missing.When I open the job configuration, I can still see {{Inclusions (e.g.: **/*.java,**/*.groovy,**/*.gs)}} with a default v
[JIRA] (JENKINS-56580) Configuration for JaCoCo plugin doesn't generate source inclusions
Title: Message Title cristalp created an issue Jenkins / JENKINS-56580 Configuration for JaCoCo plugin doesn't generate source inclusions Issue Type: Bug Assignee: Daniel Spilker Components: job-dsl-plugin Created: 2019-03-15 10:49 Environment: Jenkins LTS 2.138.3 Job DSL plugin 1.70 JaCoCo plugin 3.0.4 Priority: Minor Reporter: cristalp I configure the JaCoCo plugin by hand, trying to be as specific as possible: The paths are all configured for my project (wdl-util). In the GUI, I can see Inclusions (e.g.: */.java,*/.groovy,*/.gs), which translates to the following in config.xml : "jacoco@3.0.4"> **/wdl-util/**/target/**.exec **/wdl-util/**/target/classes **/wdl-util/**/src/main/java **/*.java **/*.class **/*Test*.class ... When I run the job, this is what I see: [JaCoCo plugin] Collecting JaCoCo coverage data... [JaCoCo plugin] **/wdl-util/**/target/**.exec;**/wdl-util/**/target/classes;**/wdl-util/**/src/main/java; locations are configured [JaCoCo plugin] Number of found exec files for pattern **/wdl-util/**/target/**.exec: 1 [JaCoCo plugin] Saving matched execfiles: /ige/jenkins/work/jobs/wdl-util/workspace/wdl-util/target/jacoco.exec [JaCoCo plugin] Saving matched class directories for class-pattern: **/wdl-util/**/target/clas
[JIRA] (JENKINS-40216) Implement a pre-parameter Groovy script
Title: Message Title cristalp created an issue Jenkins / JENKINS-40216 Implement a pre-parameter Groovy script Issue Type: Improvement Assignee: Bruno P. Kinoshita Components: active-choices-plugin Created: 2016/Dec/05 9:13 AM Priority: Minor Reporter: cristalp I'm picking up again the idea I had in JENKINS-28617 : It would be great to have a Groovy script that can be run before any of the Active Choices parameter Groovy scripts are run. Most of the time, I read an XML file to construct the data for an HTML form field. But I have to do it every time (seven times for my current form), which results in redundant code and slower performance. So, my suggestion is that it should be possible to have a Groovy script that's run before all the other Groovy script run. Like for the Active Choices Reactive Reference Parameter, it should be possible to define what Groovy variables can be seen in other Groovy scripts. Add Comment
[JIRA] [active-choices-plugin] (JENKINS-32922) Persistent parameter values from earlier builds
Title: Message Title cristalp created an issue Jenkins / JENKINS-32922 Persistent parameter values from earlier builds Issue Type: New Feature Assignee: Bruno P. Kinoshita Components: active-choices-plugin Created: 12/Feb/16 4:34 PM Priority: Minor Reporter: cristalp The ActiveChoices plugin should be able to remember the parameter value with which it was last run. This is similar to https://wiki.jenkins-ci.org/display/JENKINS/Persistent+Parameter+Plugin - but of course it's dynamic. Given: Parameter A can be set to foo and bar and ActiveChoices sets parameter B accordingly to baz and qux. If I flag parameter A as persistent, and since parameter B depends on parameter A: If A was last run with the value bar, then parameter B will be set to qux dynamically. However, if parameter B is also persistent, it doesn't behave in a dynamic way and is set to whatever was chosen during the last run, for instance baz. This could be implemented as a global option for all parameters to make this the default value, or could be under the Advanced... section of each parameter.
[JIRA] [active-choices-plugin] (JENKINS-32827) Add the possibility to hide form elements within Active Choice
Title: Message Title cristalp created an issue Jenkins / JENKINS-32827 Add the possibility to hide form elements within Active Choice Issue Type: New Feature Assignee: Bruno P. Kinoshita Components: active-choices-plugin Created: 08/Feb/16 8:19 AM Priority: Minor Reporter: cristalp I have a form that is a bit complex, because I'm generating Jenkins Jobs using the Job DSL plugin. We have different types of projects/jobs, and they all require different parameters to be given. The best I can do now (thanks to Ioannis Moutsatos) is to hide the value. However, the parameter name and description are still visible, which is potentially confusing: You can see the parameter, but you can't change it. So I propose that Active Choices should be able to hide a parameter completely. For instance, under Advanced... there could be three radio buttons with the label Visible: Always Groovy script Scriptler script Of course, the scripts must return a boolean value, and ideally Active Choice would check that.
[JIRA] [active-choices-plugin] (JENKINS-28617) Implement a pre-parameter Groovy script for totally dynamic parameters
Title: Message Title cristalp closed an issue as Fixed Jenkins / JENKINS-28617 Implement a pre-parameter Groovy script for totally dynamic parameters Change By: cristalp Status: Open Closed Resolution: Fixed Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [active-choices-plugin] (JENKINS-28617) Implement a pre-parameter Groovy script for totally dynamic parameters
Title: Message Title cristalp commented on JENKINS-28617 Re: Implement a pre-parameter Groovy script for totally dynamic parameters I finally got around to use the AC Reactive Reference parameter - what a cool feature! I can do (almost) everything I need with it, so I'm going to close the issue. The only thing that would be great is to be able to run a Groovy script beforehand, because now I'm reading the same XML three times, because I need the data in three different Reactive Reference parameters. But that's just a minor niggle. I still have some questions about the layout, but I'll ask these on the mailing list. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [active-choices-plugin] (JENKINS-28617) Implement a pre-parameter Groovy script for totally dynamic parameters
Title: Message Title cristalp commented on JENKINS-28617 Re: Implement a pre-parameter Groovy script for totally dynamic parameters OK, thanks for the suggestion. I'll look into it (might take a week or two) and then get back to you. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [active-choices-plugin] (JENKINS-28617) Implement a pre-parameter Groovy script for totally dynamic parameters
Title: Message Title cristalp commented on JENKINS-28617 Re: Implement a pre-parameter Groovy script for totally dynamic parameters Well, the use case is this: The user chooses a stage (development, integration etc.) and according to that stage, the parameters are read from the XML and the form is created. I don't know if this can be done already with the Active-Choice plugin, but I couldn't get it to work that way. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [active-choices-plugin] (JENKINS-28617) Implement a pre-parameter Groovy script for totally dynamic parameters
Title: Message Title cristalp created an issue Jenkins / JENKINS-28617 Implement a pre-parameter Groovy script for totally dynamic parameters Issue Type: New Feature Assignee: Bruno P. Kinoshita Attachments: deployments.xml, screenshot.png Components: active-choices-plugin Created: 28/May/15 9:18 AM Priority: Minor Reporter: cristalp I would like to build totally dynamic parameters by reading an XML file (see attachment). My idea is that there could be a pre-parameter Groovy script, which can build parameters for the Active Choices plugin. It would have to call the plugin's API to do that, but other than that everything would be free-form. The idea is also, that when configuring the job, the Active Choices parameters would be shown as if they were created manually - that means that the name, the description etc. would be pre-filled, as it was configured by the Groovy script. It would make sense if the parameters can't be edited, but they can be moved around.
[JIRA] [nested-view-plugin] (JENKINS-26241) Nested View Plugin creates wrong links using the build server's domain name
cristalp created JENKINS-26241 Nested View Plugin creates wrong links using the build server's domain name Issue Type: Bug Assignee: Unassigned Components: nested-view-plugin Created: 29/Dec/14 1:21 PM Description: I have a nested view with two portlets: A job list and a unit test statistics grid. On one of the two, I get absolute links based on what's configured in "Manage Jenkins... Configure System... Jenkins URL" instead of just relative links starting with "/" Here's an example: My build server's DNS name is "build.foo.com", but I'm also configuring a new build server "newbuild.foo.com". I've configured on both that the Jenkins URL is "http://build.foo.com". Working on "newbuild.foo.com" shows the problem: Jenkins normally doesn't care about that configuration when creating links to jobs: For my "base" job for instance, I get base But in the Nested View Plugin, I sometimes get the URL above, but also base - which means that the configuration is used to build that link. Environment: Jenkins ver. 1.580.2 (LTS) Nested View Plugin 1.14 Project: Jenkins Priority: Major Reporter: cristalp This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-12853) The Findbugs XML file is not searched correctly with latest Maven Findbugs plugin
cristalp created JENKINS-12853:
--
Summary: The Findbugs XML file is not searched correctly with
latest Maven Findbugs plugin
Key: JENKINS-12853
URL: https://issues.jenkins-ci.org/browse/JENKINS-12853
Project: Jenkins
Issue Type: Bug
Components: findbugs
Affects Versions: current
Environment: Jenkins 1.451, Maven 3.0.4, Maven Findbugs Plugin 2.4.0,
Jenkins Findbugs Plugin 4.33
Reporter: cristalp
Assignee: Ulli Hafner
When using the Maven2/3 job type, the Findbugs XML file isn't found. However,
it is found under the following circumstances:
* Using a free-style build
* Adding {{true}} to the Maven Findbugs
configuration. But this parameter [has been
deprecated|http://mojo.codehaus.org/findbugs-maven-plugin-2.4.0/findbugs-mojo.html].
From the Maven site, it's not very clear what its behavior is: {{This has been
deprecated and is on by default. Default value is: false.}}
Even though the generated files are the same, the plugin seems to search for
the XML files in a different way.
Here's the output when the XML files are not found:
{code}
[INFO] --- findbugs-maven-plugin:2.4.0:findbugs (default) @ base-impl ---
[INFO] Fork Value is true
[java] Warnings generated: 4
[INFO] Done FindBugs Analysis
[FINDBUGS] Parsing 1 files in
/ige/jenkins/work/jobs/base/workspace/base-impl/target
[FINDBUGS] Successfully parsed file
/ige/jenkins/work/jobs/base/workspace/base-impl/target/findbugs.xml of module
Implementation of Base Services with 0 warnings.
{code}
Here's the output when the XML files are found:
{code}
[INFO] --- findbugs-maven-plugin:2.4.0:findbugs (default) @ base-impl ---
[java] Warnings generated: 4
[INFO] Done FindBugs Analysis
[FINDBUGS] Parsing 1 files in
/ige/jenkins/work/jobs/base/workspace/base-impl/target
[FINDBUGS] Successfully parsed file
/ige/jenkins/work/jobs/base/workspace/base-impl/target/findbugsXml.xml of
module Implementation of Base Services with 4 warnings.
{code}
Also see the [discussion on the mailing
list|http://groups.google.com/group/jenkinsci-users/browse_thread/thread/0d4d5d006b93e4d4#].
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
