Jenkinsfile: qualityGate DELTA

[jukzi]

do not fail build if total number of warnings have been reduced

see #989 (comment)

[laeubi]

I think this is best reviewed by @akurtakov in general I think changes should not introduce new warnings (or use @suppresswarning if unavoidable) but if it helps we allow to introduce a new one if another is fixed instead I can't judge.

[github-actions]

Test Results

     270 files  ±0       270 suites  ±0   46m 46s ⏱️ + 3m 56s
  3 329 tests ±0    3 299 ✔️ ±0  30 💤 ±0  0 ❌ ±0 
10 284 runs  ±0  10 194 ✔️ ±0  90 💤 ±0  0 ❌ ±0 

Results for commit dd481a1. ± Comparison against base commit eeff809.

[akurtakov]

I think I gave a better fix at the linked PR which removes the need for the "workaround" field. This happened only because of the threshold gate pointing the new issue thus I believe we should keep things as they are right now and not accept this one.

[jukzi]

I think I gave a better fix at the linked PR which removes the need for the "workaround" field. This happened only because of the threshold gate pointing the new issue thus I believe we should keep things as they are right now and not accept this one.

I totally agree that that particular solution is better, however in general it would be good to just reduce warnings insted of complaining about moved warnings.

[akurtakov]

Let's try with stricter rules, if/when we have it preventing to fix things I will change my mind immediately.
FWIW, I consider this one an experiment about how strict we can go in order to get cleaner codebase.

[akurtakov]

Please don't close this PR for now - it may be something we just apply soon if needed.

[laeubi]

Please don't close this PR for now - it may be something we just apply soon if needed.

I converted it to a draft in the meanwhile.

[laeubi]

By the way, have you noticed how all checks are green now (including licence check)?

[jukzi]

By the way, have you noticed how all checks are green now (including licence check)?

gj!

[akurtakov]

Step by step, we are really going towards far better development process! Of course it has its growing pains but there is always a price.

[HannesWell]

By the way, have you noticed how all checks are green now (including licence check)?

That's very nice. 👍🏽

I think I gave a better fix at the linked PR which removes the need for the "workaround" field. This happened only because of the threshold gate pointing the new issue thus I believe we should keep things as they are right now and not accept this one.

I totally agree that that particular solution is better, however in general it would be good to just reduce warnings insted of complaining about moved warnings.

Of course the best would be to not introduce new warnings, but having one new if ten are fixed is also a win.
However will this setting also permit a one-to-one replacement? Then I would say it is usually not an advantage.

[laeubi]

if one thinks the change is good even though it introduce a new warning there is always the option to merge it anyways for "edge-cases"...

[akurtakov]

@HannesWell as PL please make a decision on this one and either merge or close. It's good to keep the PRs queue shorter :) .

[HannesWell]

@HannesWell as PL please make a decision on this one and either merge or close. It's good to keep the PRs queue shorter :) .

I agree with Christoph's opinion on this. In general it should be attempted to not introduce new warnings and I'm convinced it is usually possible. But yes, in edge-cases it is still possible to overrule a failing quality-gate and submit changes nevertheless.

[laeubi]

I just wanted to make you aware that there is an open pull request to add an option to only fail the quality gate but do not change the overall build result here:

• [JENKINS-72059] Add new quality gate options to alter the stage only jenkinsci/warnings-ng-plugin#1649

so if anyone is interested please express your support there!