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

Obtain parallel warnings results in pipeline

    XMLWordPrintable

Details

    • 5.0.0-beta2

    Description

      I currently use the warnings plugin in a pipeline build by simply calling the build step. Doing this sets the build result to unstable, so I was checking that during the pipeline to determine whether some extra steps to run.

      Specifically, I have a parallel build, which builds on multiple different configurations in parallel, and I want to rename the log file for each build to "unstable" only if that configuration got warnings. However, the build result is global for the whole pipeline. How can I obtain the number of warnings or the "result" of the warnings step in such a way that each parallel invocation can get its own results? This allows me to rename my logged files so that users who look at the final results can quickly determine which configurations were faulty?

      Attachments

        Issue Links

          Activity

            drulli Ulli Hafner added a comment -

            Can you please describe in more detail what should work? Maybe you can write a small sketch of the scripts you would expect to work. I do not use pipelines on my own so it is hard to understand the actual requirement.

            drulli Ulli Hafner added a comment - Can you please describe in more detail what should work? Maybe you can write a small sketch of the scripts you would expect to work. I do not use pipelines on my own so it is hard to understand the actual requirement.
            drulli Ulli Hafner added a comment -

            Please also check if this is a duplicate of the referenced issues.

            drulli Ulli Hafner added a comment - Please also check if this is a duplicate of the referenced issues.
            jekeller Jacob Keller added a comment -

            JENKINS-30551 is related but not identical to this issue.

            Basically, what I want to be able to do is to run the warnings plugin inside a parallel branch, so that I can scan warnings for a particular log file generated differently for each parallel branch. In this case, each branch is running on a separate node, and each node is a different version of the Linux Kernel, I am compiling a driver.

            I need to be able to determine the outcome of the warnings step inside the parallel branch. Unfortunately, the warnings plugin sets the entire job status, so if I just check the buildStatus variable directly, I am unable to determine whether the failure was this node or some other node, as the process is being run in parallel.

            Ideally, a separate pipeline specific step would be introduced which can run the warnings plugin and throws an exception when it fails. I could then catch the exception in the pipeline script, and handle it in various ways. My current job wants to rename a file to indicate whether the log has warnings or not.

            Finally, JENKINS-30551 is about making the display of multiple parallel branches work correctly which is a good thing but is not exactly related to my problem.

            jekeller Jacob Keller added a comment - JENKINS-30551 is related but not identical to this issue. Basically, what I want to be able to do is to run the warnings plugin inside a parallel branch, so that I can scan warnings for a particular log file generated differently for each parallel branch. In this case, each branch is running on a separate node, and each node is a different version of the Linux Kernel, I am compiling a driver. I need to be able to determine the outcome of the warnings step inside the parallel branch. Unfortunately, the warnings plugin sets the entire job status, so if I just check the buildStatus variable directly, I am unable to determine whether the failure was this node or some other node, as the process is being run in parallel. Ideally, a separate pipeline specific step would be introduced which can run the warnings plugin and throws an exception when it fails. I could then catch the exception in the pipeline script, and handle it in various ways. My current job wants to rename a file to indicate whether the log has warnings or not. Finally, JENKINS-30551 is about making the display of multiple parallel branches work correctly which is a good thing but is not exactly related to my problem.
            drulli Ulli Hafner added a comment -

            I see. This is not supported yet. (Is there another plug-in that works this way?)

            drulli Ulli Hafner added a comment - I see. This is not supported yet. (Is there another plug-in that works this way?)
            jekeller Jacob Keller added a comment -

            For example, in a pipeline, you can do something like:

            try {
            sh "some-command"
            catch (err) {
            "do stuff"
            }

            In a regular build, you would run shell script as part of the main build steps, and when the shell returns with a negative error code, the build result would become failure.

            However, the warnings plugin is run via the generic "step()" pipeline, and instead of returning an error or throwing an exception, the step literally sets the build status. This doesn't work in parallel since the whole build has a single status, and each parallel branch might result in different build status, and thus conflict.

            What I want is a new "scanWarnings" step which is a pipeline specific step we could call, and it would throw an exception, which we could catch in the pipeline code.

            It might be worth getting some input from someone who uses pipelines more?

            jekeller Jacob Keller added a comment - For example, in a pipeline, you can do something like: try { sh "some-command" catch (err) { "do stuff" } In a regular build, you would run shell script as part of the main build steps, and when the shell returns with a negative error code, the build result would become failure. However, the warnings plugin is run via the generic "step()" pipeline, and instead of returning an error or throwing an exception, the step literally sets the build status. This doesn't work in parallel since the whole build has a single status, and each parallel branch might result in different build status, and thus conflict. What I want is a new "scanWarnings" step which is a pipeline specific step we could call, and it would throw an exception, which we could catch in the pipeline code. It might be worth getting some input from someone who uses pipelines more?
            drulli Ulli Hafner added a comment - I found some documentation about doing this: https://github.com/jenkinsci/workflow-step-api-plugin/blob/master/README.md .
            jekeller Jacob Keller added a comment -

            Right, that outline is how to add a new step which is pretty much what we want to do, I think. Ideally we would have some way of actually obtaining the results of the warnings directly in groovy so that the groovy code could make all the decisions based on those results.

            jekeller Jacob Keller added a comment - Right, that outline is how to add a new step which is pretty much what we want to do, I think. Ideally we would have some way of actually obtaining the results of the warnings directly in groovy so that the groovy code could make all the decisions based on those results.
            jekeller Jacob Keller added a comment -

            Specifically, what I want is to be able to get the WarningsResult for a given run of the warnings step, so I can encode the logic of how to respond to warnings inside the pipeline code.

            I need to be able to run 8 nodes in parallel, each compiling on a different distribution, and see warnings for each one, and I'd like to be able to individually label the files as "UNSTABLE" without racing against other warning results. The current problem is that currentBuild.result doesn't work well because any of the 8 nodes could finish first, and make the build result Unstable, which means I could label the wrong files as unstable, when that node didn't produce warnings.

             

            I want a way to programatically say "this node had warnings, and this one didn't"

            jekeller Jacob Keller added a comment - Specifically, what I want is to be able to get the WarningsResult for a given run of the warnings step, so I can encode the logic of how to respond to warnings inside the pipeline code. I need to be able to run 8 nodes in parallel, each compiling on a different distribution, and see warnings for each one, and I'd like to be able to individually label the files as "UNSTABLE" without racing against other warning results. The current problem is that currentBuild.result doesn't work well because any of the 8 nodes could finish first, and make the build result Unstable, which means I could label the wrong files as unstable, when that node didn't produce warnings.   I want a way to programatically say "this node had warnings, and this one didn't"
            drulli Ulli Hafner added a comment -

            This is quite related to the other pipeline requirements. I think I need to split the whole reporting code into several steps that can be used independently from each other in a pipeline.

            drulli Ulli Hafner added a comment - This is quite related to the other pipeline requirements. I think I need to split the whole reporting code into several steps that can be used independently from each other in a pipeline.
            jekeller Jacob Keller added a comment -

            Note that this can't even be done currently with the currentBuild.rawBuild manually. Even if you manage to get the actions, there's no way to tell which WarningsResultAction actually contains the warnings you care about, since the ParserResult doesn't store which workspace files it scans.

            jekeller Jacob Keller added a comment - Note that this can't even be done currently with the currentBuild.rawBuild manually. Even if you manage to get the actions, there's no way to tell which WarningsResultAction actually contains the warnings you care about, since the ParserResult doesn't store which workspace files it scans.
            jekeller Jacob Keller added a comment -

            Actually, I think all you need to do is create a step which takes a parser configuration and creatse a FileParser object, execute it, and return the ParserResult... That might not be too complicated.

            jekeller Jacob Keller added a comment - Actually, I think all you need to do is create a step which takes a parser configuration and creatse a FileParser object, execute it, and return the ParserResult... That might not be too complicated.
            drulli Ulli Hafner added a comment -

            That is exactly what I mean. I think I will write down these ideas in a wiki page so that everybody can help to refine these requirements before I can start with an implementation...

            drulli Ulli Hafner added a comment - That is exactly what I mean. I think I will write down these ideas in a wiki page so that everybody can help to refine these requirements before I can start with an implementation...
            drulli Ulli Hafner added a comment -

            I'm trying to consolidate the requirements for the static analysis suite in pipeline jobs in a wiki page. Can you please read it carefully and comment or change it accordingly?

            drulli Ulli Hafner added a comment - I'm trying to consolidate the requirements for the static analysis suite in pipeline jobs in a wiki page . Can you please read it carefully and comment or change it accordingly?
            drulli Ulli Hafner added a comment -

            Released in 5.0.0-beta2.

            drulli Ulli Hafner added a comment - Released in 5.0.0-beta2.

            People

              drulli Ulli Hafner
              jekeller Jacob Keller
              Votes:
              4 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: