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

MultiJob plugin should differ when the same job is used multiple times

XMLWordPrintable

    • Icon: Improvement Improvement
    • Resolution: Postponed
    • Icon: Major Major
    • multijob-plugin
    • None
    • Jenkins ver 1.609.1
      MultiJob ver 1.20

      Within a MultiJob project, we use the same job multiple times within a phase and in multiple phases. Each job gets its own set of parameters to do the work for a specific environment. We use 'Predefined parameters' to provide the parameters to the job.

      This run fine, but each job shows the same results in the different columns.
      Taken your example plugin configuration in account, if there are multiple 'echo1' jobs the columns shows the same output on every job with the samen name. For example the 'Last Success' column shows exact the same time.
      Even when a jobs are disabled it shows the results of the last performed job.

      Presenting/storing the results for each job should be possible on a extra configuration option.
      For example like the 'Set Build Name' option. There it is a free tekst field which can take just text and/or environment vars like this #${ENV, var="MY_ENVIRONMENT_VAR"}

      This would be an nice option to show visually the difference between the jobs and it could be used to gather the results specific for that job.
      When a job is disabled it shouldn't show results, but should present itself as disabled.

          [JENKINS-31846] MultiJob plugin should differ when the same job is used multiple times

          Theo van Essen created issue -

          Robby Klehm added a comment -

          I added a job twice to a MultiJob phase but with different predefined parameters. The jobs are this way controlled by parameters and can be reused at several environments.

          Running this MultiJob phase the job output displays the same values at the parameters where different values are passed.

          As a workaround I copied the job without change and added the copied job to the phase. Running the MultiJob phase with this workaround (the job and the copied job) the different predefined parameters are passed correctly.

          I think this issue meets the one originally filed.

          Robby Klehm added a comment - I added a job twice to a MultiJob phase but with different predefined parameters. The jobs are this way controlled by parameters and can be reused at several environments. Running this MultiJob phase the job output displays the same values at the parameters where different values are passed. As a workaround I copied the job without change and added the copied job to the phase. Running the MultiJob phase with this workaround (the job and the copied job) the different predefined parameters are passed correctly. I think this issue meets the one originally filed.

          ba gage added a comment -

          Same setup and same issue here. I would like to avoid cloning jobs for only a different parameter, I actually came back from this because it was unmanageable. Looking forward to any (proper) workaround.

          ba gage added a comment - Same setup and same issue here. I would like to avoid cloning jobs for only a different parameter, I actually came back from this because it was unmanageable. Looking forward to any (proper) workaround.

          Theo van Essen added a comment -

          Thank you for looking at the issue.
          Copying could be a temporal solution, but not what you should want. A solution without unnecessary copied jobs would be nice.

          Theo van Essen added a comment - Thank you for looking at the issue. Copying could be a temporal solution, but not what you should want. A solution without unnecessary copied jobs would be nice.

          Raphael Pigulla added a comment -

          +1 from me. We run the same job in parallel many dozen times with different parameters. Making copies for each variant is neither desirable nor practical.

          Raphael Pigulla added a comment - +1 from me. We run the same job in parallel many dozen times with different parameters. Making copies for each variant is neither desirable nor practical.
          R. Tyler Croy made changes -
          Workflow Original: JNJira [ 167305 ] New: JNJira + In-Review [ 182679 ]

          Brenden Conte added a comment - - edited

          same issue, would love to see fixed (or help fix it)

          And by extension, include the <PROJECT>_<NUM>_BUILDNAME alongside NUMBER and RESULT for multi-run projects.

          Brenden Conte added a comment - - edited same issue, would love to see fixed (or help fix it) And by extension, include the <PROJECT>_<NUM>_BUILDNAME alongside NUMBER and RESULT for multi-run projects.
          Kevin Phillips made changes -
          Link New: This issue relates to JENKINS-44584 [ JENKINS-44584 ]

          Miro Zorboski added a comment -

          +1 We use MultiJob a lot on our project. We need status to be shown correctly when same job is used multiple times with different parameters in one or multiple phases. Making wrapper jobs just to achieve this is not maintainable solution.

          Miro Zorboski added a comment - +1 We use MultiJob a lot on our project. We need status to be shown correctly when same job is used multiple times with different parameters in one or multiple phases. Making wrapper jobs just to achieve this is not maintainable solution.

          Yoram Michaeli added a comment -

          Closing issue as part of tikal-multijob-plugin issues cleanup.
          If still relevant, please open a matching issue in https://github.com/jenkinsci/tikal-multijob-plugin/issues (you can refer to this issue in its description)

          Yoram Michaeli added a comment - Closing issue as part of tikal-multijob-plugin issues cleanup. If still relevant, please open a matching issue in https://github.com/jenkinsci/tikal-multijob-plugin/issues (you can refer to this issue in its description)
          Yoram Michaeli made changes -
          Resolution New: Postponed [ 6 ]
          Status Original: Open [ 1 ] New: Closed [ 6 ]

            Unassigned Unassigned
            theo42 Theo van Essen
            Votes:
            11 Vote for this issue
            Watchers:
            11 Start watching this issue

              Created:
              Updated:
              Resolved: