Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-33554

Warning threshold defaults generated by the Job DSL Plugin don't match the GUI defaults

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Minor
    • Resolution: Unresolved
    • Component/s: job-dsl-plugin
    • Labels:
      None
    • Environment:
      jenkins 1.625.3 LTS
      job-dsl plugin 1.42
      xunit plugin 1.93
    • Similar Issues:

      Description

      The default values for the thresholds are empty strings in the GUI, while in the Job DSL plugin they are zeroes. An empty threshold means it is not enforced, while a 0 one means there should not be any failures of this kind.

      Effectively, in the GUI the default is "enforce nothing, any number of errors is fine", while in the default DSL-generated job it's "strictly enforce everything, there should be no errors at all".

      While this bug is actually promoting good practices, it is still a bug

      Faulty job example:

      job('threshold-defaults-bug') {
        publishers {
          archiveXUnit {
            jUnit {
              pattern('test-results.xml')
            }
          }
        }
      }
      

      You can run it here: http://job-dsl.herokuapp.com/. Note that all the generated thresholds have 0s, not empty strings.

        Attachments

          Activity

          Hide
          ldez Ludovic Fernandez added a comment - - edited

          This issue has been already reported, see https://github.com/jenkinsci/job-dsl-plugin/pull/725

          Show
          ldez Ludovic Fernandez added a comment - - edited This issue has been already reported, see https://github.com/jenkinsci/job-dsl-plugin/pull/725
          Hide
          coffeecup_winner Dmitry Polyanitsa added a comment -

          Ludovic Fernandez, yep, I am the MR author. The MR was only partially accepted (you can't see the original commit since I've amended it). The part that was not accepted is now this issue (as requested by Daniel).

          Show
          coffeecup_winner Dmitry Polyanitsa added a comment - Ludovic Fernandez , yep, I am the MR author. The MR was only partially accepted (you can't see the original commit since I've amended it). The part that was not accepted is now this issue (as requested by Daniel).
          Hide
          petrikvandervelde Petrik van der Velde added a comment -

          Also note that the same is true for the skipped tests section, which means the DSL defaults enforce that you should never have any skipped tests, while the UI allows you to do that.

          Unfortunately we have tests that we skip, pretty much in every build. So if we want to use the ArchiveXUnit capabilities we have to generate our own configure block.

          Would be really nice to have this fixed in some way.

          Personally I don't think being backwards compatible with a known incompatibility is a good thing. But in the end I only care about having it fixed.

          Show
          petrikvandervelde Petrik van der Velde added a comment - Also note that the same is true for the skipped tests section, which means the DSL defaults enforce that you should never have any skipped tests, while the UI allows you to do that. Unfortunately we have tests that we skip, pretty much in every build. So if we want to use the ArchiveXUnit capabilities we have to generate our own configure block. Would be really nice to have this fixed in some way. Personally I don't think being backwards compatible with a known incompatibility is a good thing. But in the end I only care about having it fixed.

            People

            • Assignee:
              daspilker Daniel Spilker
              Reporter:
              coffeecup_winner Dmitry Polyanitsa
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated: