|
||||||||
|
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.
Well, now the WHAT is out of the way, if you care to hear the WHY, it might help you understand my blight.
In an ideal project scenario, you would set-up CPP check from the outset, ensuring you have very few errors. However, I joined a large system project and implemented CPP check very late in the day. There are some lines of code that are more than 30 years old! With that in mind, you might appreciate there being lots of warnings and errors. Unfortunately, there are thousands of errors as opposed to hundreds. Whilst we could ignore them, we actually want to fix them all, in time. I have filtered out about 10000 errors, leaving around 2500 errors I think should be fixed. However, time is not on our side, so what I have implemented is a Jenkins post build step that actually uses the Jenkins CLI to reduce the threshold after each build, whenever someone fixes a warning or error. This ensures we can't introduce any new errors and continue to fix the existing errors.
So as you might imagine, when there are thousands of errors, it's extremely difficult to see the wood through the trees, or as in our case, the new errors amongst the unchanged errors. We are getting there, but very slowly, which is why it's such a pain when a new error is introduced but not spotted before the next build is churned out by CI. With collaboration occurring round the clock and around the globe, it's difficult to co-ordinate commits with builds, resulting in builds very quickly pushing out the deltas before we've had a chance to look at them, especially over a weekend.
We're looking to increase the number of builds we keep, but we build deployment images as part of the build, which requires lots of space, so keeping more than ten becomes a bit tricky.
As I say, I'm happy to provide a generic solution, it'll just take me some time to fit around my usual workload.