Hi Robert,

I do not exactly understand what's wrong with the current implementation. throttle() step works well without Parallel, e.g. the following sample works well:

throttle(['test_2']) {
  node() {
        sh "sleep 500"
        echo "Done"
  }
}

The thing is that the Pipeline actually starts, but node() step will synchronize on the category

Anyway, it worth providing such example in the docs

I have done the following:
case (target_option != "HOST" && comp_tool == "ARM"):
throttle(['ARM_LICENSES'])
{
stage("Build libraries")
{
try
{
sh ''' mkdir BUILD
cd BUILD
cmake -GNinja -DCTEST_GENERATE_XUNIT_FILES=ON -DCMAKE_TOOLCHAIN_FILE=$CBS/toolchains/ARMCortexR4Toolchain.cmake -DCBS_RUN_VPUML=OFF ${WORKSPACE}/sdmos/cmake/targets/repository
ninja -v '''
currentBuild.result = "${env.job_pass}"
}
catch (Exception err)
{
currentBuild.result = "${env.job_fail}"
CommonUtilities.stage_failure("Build libraries")
println err
throw err
}
}
}

If it set ARM_LICENSES to 2 in Jenkins config then trigger threee pipelines that has this in I see all three jobs running the build stage at the same time.
Do I need to move to beore the node as in the example?

Yes, throttling will work on the node() level only. so the node() definition should be within the throttle() block.

abayer just to be flexible with support of other throttling scopes, maybe we could add something like a  ThrottlePlaceholderTask? Maybe a flyweight one... It would be similar with node() acquisition logic, which is not a state of the art design though. But it would help. WDYT?

Ok if I put it before node then the other job waits.
Thanks for the help

If you do not mind, let's keep this bug open. I will discuss it with abayer and probably convert it to RFE

Ok happy to give feedback

In a pipeline job we do sometimes have two build stages one might use the arm license and another build in the same pipeline might use msbuild to build a host exe. It would be good to be able to limit the arm build but allow msbuild builds to run without any throttling.

Code changed in jenkins
User: Oleg Nenashev
Path:
README.md
http://jenkins-ci.org/commit/throttle-concurrent-builds-plugin/ad8072a541fcacc0175b6468092e19392e0b91e4
Log:
JENKINS-44411 - Extend documentation to clarify throttle() behavior and supported use-cases

Code changed in jenkins
User: Oleg Nenashev
Path:
README.md
http://jenkins-ci.org/commit/throttle-concurrent-builds-plugin/68f1f3fa1cd3d96ae71675008bbff0e4ba61ab52
Log:
JENKINS-44411 - Drop the confusing sentence

Code changed in jenkins
User: Oleg Nenashev
Path:
README.md
http://jenkins-ci.org/commit/throttle-concurrent-builds-plugin/7c61f6119c67ffb046bcf3afb596671b12011bd8
Log:
Merge pull request #49 from oleg-nenashev/docs/JENKINS-44411-clarify-throttle-step

JENKINS-44411 - Extend documentation to clarify throttle() behavior

Compare: https://github.com/jenkinsci/throttle-concurrent-builds-plugin/compare/1497858da1f6...7c61f6119c67

The new documentation is now clear on the use of throttle for pipelines.

Hi, any update on support of declarative pipeline flows ? 
Thanks

Hi, we switched to the lock-Plugin for this use case:
https://wiki.jenkins.io/display/JENKINS/Lockable+Resources+Plugin

Worked as aspected

Lockable resources solves some use cases in declarative pipelines, but not all.

I want to limit builds of a declarative pipeline project to one build per node. I can't achieve this.

The documentation in "Example 3: Throttling of declarative pipelines" is lacking/misguiding. I've tested, and it has no throttling effect on a single declarative Pipeline job. Does it only throttle between jobs using same category? (And in that case, are different branches in a multi-branch pipeline considered different jobs?) IMHO, that feature is not as useful as being able to throttle on the same job.