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

Use stage as a resource lock

    XMLWordPrintable

    Details

    • Type: New Feature
    • Status: Resolved (View Workflow)
    • Priority: Minor
    • Resolution: Duplicate
    • Component/s: pipeline
    • Labels:
      None
    • Similar Issues:

      Description

      My use case is users launching multiple jobs that use a lot of server bandwidth, so I would prefer to do something that limits the number of stages running concurrently similar to:

      stage 'start'
stage name: 'bandwidth-hog', concurrency: 5, resourceLock: true
//bandwidth hogging code
stage 'finish'

      However, I can't have newer jobs pre-empt older jobs, they should just be queued up. Of course, this could be a new step as well. Hopefully this helps others as well!

        Attachments

          Issue Links

          duplicates

          New Feature - A new feature of the product, which has yet to be developed. JENKINS-30269 Add workflow support for resource locking

          • Major - Major loss of function.
          • Resolved
          is related to

          New Feature - A new feature of the product, which has yet to be developed. JENKINS-27039 Option for input or stage step to cancel older executions

          • Major - Major loss of function.
          • In Review

            Activity

            Ascending order - Click to sort in descending order
            anshuarya Anshu Arya created issue -
            anshuarya Anshu Arya made changes -
            Field Original Value New Value
            Link This issue is related to JENKINS-27039 [ JENKINS-27039 ]
            anshuarya Anshu Arya made changes -
            Description My use case is users launching multiple jobs that use a lot of server bandwidth, so I would prefer to do something that limits the number of stages running concurrently similar to:

            {code}
            stage 'start'
            stage name: 'bandwidth-hog', concurrency: 5, resourceLock: true
            //bandwidth hogging code
            stage 'finish'
            {code}

            It would be useful if newer jobs did not pre-empt older jobs, but just queued up. Of course, this could be a new step as well. Hopefully this helps others as well!             		My use case is users launching multiple jobs that use a lot of server bandwidth, so I would prefer to do something that limits the number of stages running concurrently similar to:

            {code}
            stage 'start'
            stage name: 'bandwidth-hog', concurrency: 5, resourceLock: true
            //bandwidth hogging code
            stage 'finish'
            {code}

            However, I can't have newer jobs pre-empt older jobs, they should just be queued up. Of course, this could be a new step as well. Hopefully this helps others as well!
            Hide
            Permalink
            jglick Jesse Glick added a comment -

            stage is not designed for this use case; a separate step would be more appropriate.

            Show
            jglick Jesse Glick added a comment - stage is not designed for this use case; a separate step would be more appropriate.
            jglick Jesse Glick made changes -
            Link This issue duplicates JENKINS-30269 [ JENKINS-30269 ]
            jglick Jesse Glick made changes -
            Resolution Duplicate [ 3 ]
            Status Open [ 1 ] Resolved [ 5 ]
            rtyler R. Tyler Croy made changes -
            Workflow JNJira [ 165884 ] JNJira + In-Review [ 197841 ]
            abayer Andrew Bayer made changes -
            Component/s pipeline-general [ 21692 ]
            abayer Andrew Bayer made changes -
            Component/s workflow-plugin [ 18820 ]

              People

              Assignee:
              jglick Jesse Glick
              Reporter:
              anshuarya Anshu Arya
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: