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

Pipeline Milestone step: Adding parameter for milestone classification

    XMLWordPrintable

    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
          jglick Jesse Glick added a comment -

          the latest released script versions [are] used by the SW development teams [so] the build script version must be specified centrally

          By the way this is easily supported in multibranch projects by moving the logic of the build into a library and then having a Jenkinsfile merely say something like

          library('standard-corporate-build@master').run()
          

          (The version identifier may be omitted if a default is specified in the library registration, and the administrator can control whether or not this version may be overridden, say to a tag or commit hash.)

          Show
          jglick Jesse Glick added a comment - the latest released script versions [are] used by the SW development teams [so] the build script version must be specified centrally By the way this is easily supported in multibranch projects by moving the logic of the build into a library and then having a Jenkinsfile merely say something like library( 'standard-corporate-build@master' ).run() (The version identifier may be omitted if a default is specified in the library registration, and the administrator can control whether or not this version may be overridden, say to a tag or commit hash.)
          Hide
          tpeitzsch Tobias Peitzsch added a comment -

          To be more concrete, the best practice "one branch, one job" will not work in large companies with separated teams for SW development and infrastructure development due to job maintenance (E.g. are the latest released script versions used by the SW development teams). Here the build script version must be specified centrally. Please think about more than 1000 different SW development projects / repositories with at least 10 branches (note: multibranch is not possible, legacy SCM) but only 4 different workflows.

          It is a hard job to change some global configurations for more 10000 jobs  (even with Jobs DSL).

          To reduce the amount of jobs I want to use one job per released pipeline script version for all related projects / repositories (or 10000 jobs running in one Job). Unfortunately the milestone step cannot be used.

          Markus Maga: Unfortunately not. I haven't found a real solution for this issue :/. E.g. the Job creation via Jobs DSL introduce additional infrastructure to handle the build parameters (some of them can be changed by the users and would be overwritten by the Jobs DSL)

          Show
          tpeitzsch Tobias Peitzsch added a comment - To be more concrete, the best practice "one branch, one job" will not work in large companies with separated teams for SW development and infrastructure development due to job maintenance (E.g. are the latest released script versions used by the SW development teams). Here the build script version must be specified centrally. Please think about more than 1000 different SW development projects / repositories with at least 10 branches (note: multibranch is not possible, legacy SCM) but only 4 different workflows. It is a hard job to change some global configurations for more 10000 jobs  (even with Jobs DSL). To reduce the amount of jobs I want to use one job per released pipeline script version for all related projects / repositories (or 10000 jobs running in one Job). Unfortunately the milestone step cannot be used. Markus Maga : Unfortunately not. I haven't found a real solution for this issue :/. E.g. the Job creation via Jobs DSL introduce additional infrastructure to handle the build parameters (some of them can be changed by the users and would be overwritten by the Jobs DSL)
          Hide
          flydiverny Markus Maga added a comment -

          Jesse Glick perhaps, suggestions welcome 

          But having milestones that can be bound to one or more parameters makes sense to me.

          But I don't see a reason not to offer this flexibility, it would give more super powers to parameterised builds

          Show
          flydiverny Markus Maga added a comment - Jesse Glick  perhaps, suggestions welcome  But having milestones that can be bound to one or more parameters makes sense to me. But I don't see a reason not to offer this flexibility, it would give more super powers to parameterised builds
          Hide
          jglick Jesse Glick added a comment -

          prevent running simultaneous deployments for the same app to the same environment

          This sort of logic should probably be moved out of Jenkins itself into a deployment tool.

          Show
          jglick Jesse Glick added a comment - prevent running simultaneous deployments for the same app to the same environment This sort of logic should probably be moved out of Jenkins itself into a deployment tool.
          Hide
          flydiverny Markus Maga added a comment -

          I've also been looking for something similar. Our use case is that we have a shared job for deployment, we have multiple multibranch jobs which all trigger a parameterised pipeline job. In this pipeline job I'd like to combine milestones & locks to prevent running simultaneous deployments for the same app to the same environment. I can use locks to only deploy one of each app at a time (different apps can deploy in parallel). But it would be nice to use the milestone with the suggested ordinalGroup in combination with locks using inversePrecedence: true. Do you have an alternative solution to this Antonio Muñiz? I see no need to have to create new jobs for each possible application & environment combination.

          Did you find any solution Tobias Peitzsch?

          Show
          flydiverny Markus Maga added a comment - I've also been looking for something similar. Our use case is that we have a shared job for deployment, we have multiple multibranch jobs which all trigger a parameterised pipeline job. In this pipeline job I'd like to combine milestones & locks to prevent running simultaneous deployments for the same app to the same environment. I can use locks to only deploy one of each app at a time (different apps can deploy in parallel). But it would be nice to use the milestone with the suggested ordinalGroup in combination with locks using inversePrecedence: true. Do you have an alternative solution to this Antonio Muñiz ? I see no need to have to create new jobs for each possible application & environment combination. Did you find any solution Tobias Peitzsch ?

            People

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

              Dates

              • Created:
                Updated: