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

    • Similar Issues:

      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

          Hide
          drulli Ulli Hafner added a comment -

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

          Show
          drulli Ulli Hafner added a comment - This is not possible. What is the reason behind this approach?
          Hide
          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.

          Show
          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.
          Hide
          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.

          Show
          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.
          Hide
          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?).

          Show
          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?).
          Hide
          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.

          Show
          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.
          Hide
          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.

          Show
          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.
          Hide
          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...

          Show
          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...

            People

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

              Dates

              • Created:
                Updated:
                Resolved: