|
||||||||
|
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.
So.
We aren't using a big honking make in a single build step.
We have many individual build steps that run typically single tool focused shell scripts.
Most of those are 'quality' scripts that are running code through various tools, and collecting data for warnings parsers.
We are attempting to use health thresh holding with static analysis to get extra attention when the mountain of technical debt grows (a containment strategy).
Since we are a big institution, nothing is resolved quickly, so sometimes jobs remain in that attention getting state for a long while (weeks to quarters), even if development of new capabilities is active in the code base that job is monitoring. Not my call. I'm just the CI tool smith, not the prioritization/funding/process manager.
Typically, an actual compile or script fault occurs < 1% of the time, but a build 'quality' health thresh hold breach is > 99% of why we have builds marked failed.
Thus, we would like SLOCCount to able to be configured to run regardless of build health.