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

Add ability to split analysis jobs within pipeline

    • 5.0.0-beta2

      Right now, if I have two steps in parallel in a single pipeline job, I get two entries in my menu on the left from the two analysis jobs. I'd like to be able to label them in some way so I can intelligently tell which is which, e.g. new option at end:

      warnings consoleParsers: [[parserName: 'GNU C Compiler 4 (gcc)']], defaultEncoding: '', excludePattern: '.*/rpmbuild/.*', healthy: '', includePattern: '', messagesPattern: '', unHealthy: '', useStableBuildAsReference: true, displayName: "CentOS ${OS} Build"
      

          [JENKINS-47669] Add ability to split analysis jobs within pipeline

          Ulli Hafner added a comment - - edited

          I think this is already considered in the requirements document, can you please check if that will work for you?

          Ulli Hafner added a comment - - edited I think this is already considered in the requirements document , can you please check if that will work for you?

          drulli I had not seen that document. I'm not sure I follow it all, sorry, but I do see under publishIssues "Merges all issues of the provided parsers into a single result." This seems to take the issue generator plugin as an option. I'm thinking a little beyond that and maybe a way to tag/label them as they go in (at scanForIssues step) that you can then only collect the subset with publishIssues.

          // This is not valid but to give you the idea
          stage("Build") {
            parsteps['Build CentOS6'] = {
              node('docker && C6') {
                do_build('C6')
                scanForIssues ..., tag: "C6_GCC"
              }
            }
            parsteps['Build CentOS7'] = {
              node('docker && C7') {
                do_build('C7')
                scanForIssues ..., tag: "C7_CLANG"
              }
            }
            parallel parsteps
          }
          stage("Publish") {
            publishIssues ..., tag: "C6_GCC" , displayName: "CentOS 6 Compiler Warnings"
            publishIssues ..., tag: "C7_CLANG" , displayName: "CentOS 7 Compiler Warnings"
          }
          

          Aaron D. Marasco added a comment - drulli I had not seen that document. I'm not sure I follow it all, sorry, but I do see under publishIssues "Merges all issues of the provided parsers into a single result." This seems to take the issue generator plugin as an option. I'm thinking a little beyond that and maybe a way to tag/label them as they go in (at scanForIssues step) that you can then only collect the subset with publishIssues. // This is not valid but to give you the idea stage( "Build" ) { parsteps[ 'Build CentOS6' ] = { node( 'docker && C6' ) {      do_build( 'C6' ) scanForIssues ..., tag: "C6_GCC" } } parsteps[ 'Build CentOS7' ] = { node( 'docker && C7' ) {      do_build( 'C7' ) scanForIssues ..., tag: "C7_CLANG" } } parallel parsteps } stage( "Publish" ) { publishIssues ..., tag: "C6_GCC" , displayName: "CentOS 6 Compiler Warnings" publishIssues ..., tag: "C7_CLANG" , displayName: "CentOS 7 Compiler Warnings" }

          Ulli Hafner added a comment -

          Actually the scanForIssues step returns a result (the warnings), i.e. your code will look like:

          do_build('C6')
          def c6Gcc = scanForIssues ...
          

          I'm not sure if the variable is then visible in the Publish stage scope. If not you need to write:

          do_build('C6')
          def c6Gcc = scanForIssues ...
          publishIssues ..., issues:c6Gcc, id="c6gcc" name: "CentOS 6 Compiler Warnings"
          

          Ulli Hafner added a comment - Actually the scanForIssues step returns a result (the warnings), i.e. your code will look like: do_build('C6') def c6Gcc = scanForIssues ... I'm not sure if the variable is then visible in the Publish stage scope. If not you need to write: do_build('C6') def c6Gcc = scanForIssues ... publishIssues ..., issues:c6Gcc, id="c6gcc" name: "CentOS 6 Compiler Warnings"

          Yeah, the variable scope stuff is still confusing to me, I think @Field fixes most of it... But anyway, yeah, what you have there with an id/name is what I'm looking for.

          Aaron D. Marasco added a comment - Yeah, the variable scope stuff is still confusing to me, I think @Field fixes most of it... But anyway, yeah, what you have there with an id/name is what I'm looking for.

          Ulli Hafner added a comment -

          Released in 5.0.0-beta2.

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

            drulli Ulli Hafner
            aarondmarasco_vsi Aaron D. Marasco
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: