warnings-ng plug-in in a matrix job

28 views
Skip to first unread message

Braden McDaniel

unread,
Jan 21, 2019, 1:49:24 PM1/21/19
to Jenkins Users
I have a matrix job that builds on multiple compilers/platforms. One of those compilers is clang with static analysis.

I have recently discovered the warnings-ng plug-in; and while it seems quite clever, because it operates as a post-build action (and the conditional step plug-in does not provide conditional steps in post-build), I do not see how to enable it only for the portion of the matrix where clang's static analysis is run.

Is there a way to get this sort of result within the matrix job?

Ullrich Hafner

unread,
Jan 21, 2019, 2:01:17 PM1/21/19
to Jenkins Users
Does the plugin fail the job for the other axes? Or can’t you just pick a file that is empty for the other axes? 

Currently there is no way to configure different properties for different axes.

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/14213f8f-251d-4544-b190-f4c71651a1f6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Braden McDaniel

unread,
Jan 22, 2019, 12:52:56 PM1/22/19
to Jenkins Users
On Monday, January 21, 2019 at 2:01:17 PM UTC-5, Ullrich Hafner wrote:
Does the plugin fail the job for the other axes? Or can’t you just pick a file that is empty for the other axes? 

Currently there is no way to configure different properties for different axes.

Thanks for pointing out that the plug-in can be directed to a specific file rather than just parsing the console log; I'd overlooked that.

The solution in my case was to save off the build log from clang analysis and make it an artifact of the matrix job. It then gets pulled to a multijob that called the matrix job; the warnings-ng plug-in is used on the multijob rather than the matrix job.

I believe this is the right solution for my scenario. My matrix job has a number of configuration parameters; and it gets called by a few different multijobs that apply different parameters. The nature of these parameters means that applying warnings-ng to the matrix job would not result in very useful history. (I.e., the job history would include builds of disparate branches.) Applying warnings-ng to the parent multijobs means the histories will be a good deal more coherent.

Reply all
Reply to author
Forward
0 new messages