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

Add the possibility to ignore the list of base warnings from the build of another job

    XMLWordPrintable

Details

    • 5.0.0-beta2

    Description

      I have a job A producing some reference warnings (the job is typically run only once).
      Then i have a job B for which i want to substract the set of warnings created by job A before checking new warnings.
      Is there currently a way to do this?

      Attachments

        Activity

          chantivlad chanti vlad created issue -
          drulli Ulli Hafner added a comment -

          This is not possible. What is the reason behind this approach?

          drulli Ulli Hafner added a comment - This is not possible. What is the reason behind this approach?
          chantivlad chanti vlad added a comment -

          The reason is simple: eliminate some warnings based on some reference set of warnings before code modification.
          What i want is the possibility to do a diff, or to ignore some warnings fro job B if they are present in my reference job A.

          chantivlad chanti vlad added a comment - The reason is simple: eliminate some warnings based on some reference set of warnings before code modification. What i want is the possibility to do a diff, or to ignore some warnings fro job B if they are present in my reference job A.

          I'm working on a project in which we have a Jenkins job called Master, which builds our master branch in Git whenever there is a change on it, and also a job called Merge Request, which is build whenever someone submits a pull request to the master branch.

          The Merge Request build takes care of validating if the pull request meets some quality levels like not introducing any new warning. The problem is that as many people may submit pull requests of their own work, the Warnings plugin ends up getting both new and fixed warnings between two different people's work rather than between someone's changes and the master branch status.

          It would be nice if we could make the Master build job in Jenkins generate the warnings baseline reflecting the master branch state, and then have the Merge Request build job to always compute new and fixed warnings using this baseline from the other job.

          tmanhente Thiago Marques added a comment - I'm working on a project in which we have a Jenkins job called Master, which builds our master branch in Git whenever there is a change on it, and also a job called Merge Request, which is build whenever someone submits a pull request to the master branch. The Merge Request build takes care of validating if the pull request meets some quality levels like not introducing any new warning. The problem is that as many people may submit pull requests of their own work, the Warnings plugin ends up getting both new and fixed warnings between two different people's work rather than between someone's changes and the master branch status. It would be nice if we could make the Master build job in Jenkins generate the warnings baseline reflecting the master branch state, and then have the Merge Request build job to always compute new and fixed warnings using this baseline from the other job.
          drulli Ulli Hafner added a comment -

          I see, this makes much more sense than the original request. I.e., all we need to do is to switch the reference build. Is your reference build always the latest available build of the master job? Or is the build number somehow fixed (and if yes, where can we obtain the build number from?).

          drulli Ulli Hafner added a comment - I see, this makes much more sense than the original request. I.e., all we need to do is to switch the reference build. Is your reference build always the latest available build of the master job? Or is the build number somehow fixed (and if yes, where can we obtain the build number from?).

          Yes, the reference build would be always the latest available build of our master job, at least in the project I'm currently working with.

          In case someone needs a finer control of the build to use as reference, however, one idea that came to me is to Warnings plugin to provide a post-build action like "store reference warnings". It could provide options like "In every build", "Only stable builds" or "Only non-failed builds". The user could then use it to choose exactly when he/she wants to update the reference warnings (either for that own job or for other jobs), specially if used together with Conditional Build Step plugin or Workflow plugin. This could work somewhat similar to the Clone Workspace SCM.

          tmanhente Thiago Marques added a comment - Yes, the reference build would be always the latest available build of our master job, at least in the project I'm currently working with. In case someone needs a finer control of the build to use as reference, however, one idea that came to me is to Warnings plugin to provide a post-build action like "store reference warnings". It could provide options like "In every build", "Only stable builds" or "Only non-failed builds". The user could then use it to choose exactly when he/she wants to update the reference warnings (either for that own job or for other jobs), specially if used together with Conditional Build Step plugin or Workflow plugin. This could work somewhat similar to the Clone Workspace SCM.
          chantivlad chanti vlad added a comment -

          "I see, this makes much more sense than the original request." --> i don't really see how.
          anyway, i implemented a solution for my problem, maybe i can close this ticket.

          chantivlad chanti vlad added a comment - "I see, this makes much more sense than the original request." --> i don't really see how. anyway, i implemented a solution for my problem, maybe i can close this ticket.
          drulli Ulli Hafner added a comment -

          I think the second approach is much simpler to achieve. Or did I misunderstand the original request? You want to have different set of warnings for all and new. In the second approach the same set of warnings is used, just a different reference build...

          drulli Ulli Hafner added a comment - I think the second approach is much simpler to achieve. Or did I misunderstand the original request? You want to have different set of warnings for all and new. In the second approach the same set of warnings is used, just a different reference build...
          drulli Ulli Hafner made changes -
          Field Original Value New Value
          Labels reference warnings
          rtyler R. Tyler Croy made changes -
          Workflow JNJira [ 152083 ] JNJira + In-Review [ 178174 ]
          drulli Ulli Hafner made changes -
          Labels analysis-core-2.0
          drulli Ulli Hafner made changes -
          Epic Link JENKINS-49911 [ 188901 ]
          drulli Ulli Hafner made changes -
          Resolution Fixed [ 1 ]
          Status Open [ 1 ] Resolved [ 5 ]
          drulli Ulli Hafner made changes -
          Status Resolved [ 5 ] Fixed but Unreleased [ 10203 ]
          drulli Ulli Hafner added a comment -

          Released in 5.0.0-beta2.

          drulli Ulli Hafner added a comment - Released in 5.0.0-beta2.
          drulli Ulli Hafner made changes -
          Released As 5.0.0-beta2
          Status Fixed but Unreleased [ 10203 ] Resolved [ 5 ]

          People

            drulli Ulli Hafner
            chantivlad chanti vlad
            Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: