[JENKINS-60481] Add throttleJobProperty @Symbol to ThrottleJobProperty

[bawjensen]

I pulled inspiration for this change from jenkinsci/branch-api-plugin#127, so I'm hoping it's a fairly straightforward change. In my local testing (using mvn hpi:run and then manually installing Pipeline: Declarative) I can confirm that before this change, the dropdown suggestions for the Declarative Directive Generator for options included only throttle and after this change it included both throttle and throttleJobProperty. When throttleJobProperty was selected the UI that came up was as expected for the job property exposed by this plugin.

Also tested by creating a pipeline job and setting this as its pipeline script:

pipeline {
    agent any

    options {
        throttleJobProperty(
            categories: [],
            limitOneJobWithMatchingParams: false,
            maxConcurrentPerNode: 0,
            maxConcurrentTotal: 4,
            paramsToUseForLimit: '',
            throttleEnabled: true,
            throttleOption: 'project',
        )
    }

    stages {
        stage('build') {
            agent any
            steps {
                sleep 60
                echo "done"
            }
        }
    }
}

Running 5 builds within a minute displayed the expected waiting message, and inspecting the job's configuration showed that it had been persisted as desired there.

[oleg-nenashev]

Thanks! It should definitely help users

[basil]

Thanks for your contribution, @bawjensen! I just merged your PR branch with master and applied some trivial formatting fixes. This should be a part of the forthcoming Throttle Concurrent Builds 2.0.2 release.

[bawjensen]

🙇‍♂️ thanks for the quick responses on this, @oleg-nenashev / @basil!

[rory-ye-nv]

when will 2.0.2 will be released, and @bawjensen does this support limitOneJobWithMatchingParams; true for pipeline as well?

if yes, can't wait for this feature to be released.

[rory-ye-nv]

due to this issue, it's still not work with limitOneJobWithMatchingParams https://issues.jenkins-ci.org/browse/JENKINS-37809

[basil]

when will 2.0.2 will be released

I have just released Throttle Concurrent Builds 2.0.2.

[pandorasbox963]

pipeline {
agent {
node {
label 'slave'
}
}
options {
throttleJobProperty(
categories: ['TEST'],
limitOneJobWithMatchingParams: true,
maxConcurrentPerNode: 1,
maxConcurrentTotal: 2,
paramsToUseForLimit: 'PORT',
throttleEnabled: true,
throttleOption: 'category',
)
}

parameters {
..
}

stages {
..
}

I am using above configuration and I have 2 slave nodes with label slave.
When i run the second build, it is still running on node-1, even though the limit is set to 1 (maxConcurrentPerNode: 1).
Also, i see that paramsToUseForLimit is completely being ignored. It does startup a 2nd build with same parameter value that too on the same node.
What is it that I am missing ? I would greatly appreciate any insights.

[tking16]

Same as the above unanswered question. I have 2 nodes with the label 'release-smoke-tests' but the builds are only running one 1. it says in the queue (pending—Already running 1 builds across all nodes) even though the other node is still free!

agent { label 'release-smoke-tests' }
  options {
      throttleJobProperty(
          categories: ['appium-smoke-testing-ios'],
          limitOneJobWithMatchingParams: false,
          maxConcurrentPerNode: 1,
          maxConcurrentTotal: 0,
          throttleEnabled: true,
          throttleOption: 'category',
      )
  }

[edgarkz]

Hello,
Any update on this?

[mandrije]

Hello, as explained by @pandorasbox963 above, I'm also unable to limit the number of concurrent executions per node using Throttle Concurrent Builds plugin (ver. 2.2). Pipeline behaves as if maxConcurrentPerNode wasn't set (btw maxConcurrentTotal works as expected). In my case, there are 5 nodes associated with the label I'm using in the pipeline and each one of those has 4 or more executors enabled. NOTE: all these nodes are associated with multiple labels (besides the one I'm targeting).

Is this plugin still maintained?

Update: I just came across this defect... looks like it describes the troublesome behaviour we're highlighting here.

[edgarkz]

Hi @mandrije, we had the same issue with the above plugin, since no resolution was found we switched to https://plugins.jenkins.io/build-blocker-plugin/ instead, and we were able to apply the same restrictions.

[mandrije]

Thank you very much @edgarkz! Meantime, I realized that the remaining, working options (same param values and max total restrictions) will meet my needs, but hopefully other people reading your suggestion above will benefit from it.