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

Pipeline Milestone step: Adding parameter for milestone classification

    Details

    • Similar Issues:

      Description

      Adding a parameter for milestone classification, so an older build will not override a newer build if only they belong to the same group.

      The parameter would group different milestones. The ordinal parameter is used to order the milestones in the group. The abort behavior in a group is the same as now.
      extended simplified script from above:
      sleep PARAMETER
      milestone label: 'mileStone', ordinalGroup: projectName
      sleep 5

      Example1:
      project1: started with PARAMETER = 20 (sleeps 20 sec), ordinalGroup: 'p1'
      project2: started after project1 with PARAMETER = 5, ordinalGroup: 'p2'
      --> project1 and project2 run in the same job

      Example2:
      project1: started with PARAMETER = 20 (sleeps 20 sec), ordinalGroup: 'p1'
      project2: started after project1 with PARAMETER = 5, ordinalGroup: 'p2'
      project1: started after project2 with PARAMETER = 7 (sleeps 7 sec), ordinalGroup: 'p1'
      -> first p1 is aborted through 2nd p1 build, p2 runs through.

        Attachments

          Activity

          Hide
          deiga Timo Sand added a comment -

          Use case:
          We have a single job which does PR deployments. It is triggered by each PR's own build job, but with different params, like which branch to deploy etc.

          We would like to ensure that only the latest build gets deployed as it would be unnecessary to deploy older builds. Milestones and inverse locks seemed to offer a great solution to this, but milestones don't take parameters into account at all and thus it cancels jobs which have different parameters.

          Show
          deiga Timo Sand added a comment - Use case: We have a single job which does PR deployments. It is triggered by each PR's own build job, but with different params, like which branch to deploy etc. We would like to ensure that only the latest build gets deployed as it would be unnecessary to deploy older builds. Milestones and inverse locks seemed to offer a great solution to this, but milestones don't take parameters into account at all and thus it cancels jobs which have different parameters.
          Hide
          link89 Henry Xu added a comment -

          I think this is an essential feature that needs to be implemented in milestone.

          Our pipeline is triggered by GitLab's Merge Request events. Whenever there are code updated or special comments, the job will be triggered. It is very common to have multiple builds that triggered by the same Merge Request in our pipeline.

          In this case, we would hope that old builds should be aborted if there are a new build of same Merge Request. If milestone can support classification, then we can simply write 

          milestone(groupLable: env.gitlab_merge_request_id)
          Show
          link89 Henry Xu added a comment - I think this is an essential feature that needs to be implemented in milestone. Our pipeline is triggered by GitLab's Merge Request events. Whenever there are code updated or special comments, the job will be triggered. It is very common to have multiple builds that triggered by the same Merge Request in our pipeline. In this case, we would hope that old builds should be aborted if there are a new build of same Merge Request. If milestone can support classification, then we can simply write  milestone(groupLable: env.gitlab_merge_request_id)
          Hide
          jglick Jesse Glick added a comment -

          Our pipeline is triggered by GitLab's Merge Request events.

          Note that an alternate solution in this case is to use the GitLab branch source plugin, so that each MR corresponds to a distinct job. Obviously that is a big change with other impacts.

          Show
          jglick Jesse Glick added a comment - Our pipeline is triggered by GitLab's Merge Request events. Note that an alternate solution in this case is to use the GitLab branch source plugin, so that each MR corresponds to a distinct job. Obviously that is a big change with other impacts.
          Hide
          link89 Henry Xu added a comment -

          Jesse Glick

          Actually I don't think the idea of one job per branch and the multi-branch pipeline is feasible for a large project. I think Jenkins 2.0 pipeline already grants us the ability to handle the multi-branch scenario and merge requests in a single pipeline script. Multi-branch pipeline may looks good if everything works ideally. But in the real world, we have already had to apply some global change to work around unexpected problems several times. And by using the one job per branch strategy, we still have to distinguish push events and merge events to do different things. Then why not just handle all of those conditions in a single pipeline script. It's hard for me to switch to multi-branch pipeline without any strong reason. 

          On the other hand, by providing a namespace mechanism for milestone, just as what we already had in `lock`, can be very useful and flexible in many cases.

          Show
          link89 Henry Xu added a comment - Jesse Glick Actually I don't think the idea of one job per branch and the multi-branch pipeline is feasible for a large project. I think Jenkins 2.0 pipeline already grants us the ability to handle the multi-branch scenario and merge requests in a single pipeline script. Multi-branch pipeline may looks good if everything works ideally. But in the real world, we have already had to apply some global change to work around unexpected problems several times. And by using the one job per branch strategy, we still have to distinguish push events and merge events to do different things. Then why not just handle all of those conditions in a single pipeline script. It's hard for me to switch to multi-branch pipeline without any strong reason.  On the other hand, by providing a namespace mechanism for milestone, just as what we already had in `lock`, can be very useful and flexible in many cases.
          Show
          stchar Stanislav Ovchar added a comment - Created PR  https://github.com/jenkinsci/pipeline-milestone-step-plugin/pull/17

            People

            • Assignee:
              amuniz Antonio Muñiz
              Reporter:
              carlosrodlop Carlos Rodríguez López
            • Votes:
              4 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated: