Aquire lock without using try-with-resources notation

[royteeuwen]

Describe your use-case which is not covered by existing documentation.

I'm trying to get a lock without using the try-with-resources notation, is this possible and if not through declarative then is it possible by using a scripted approach?

What I'm trying to achieve is the following:

• build stage
• deploy to X (lock X) and deploy to Y (lock Y) parallel
• test suites 1, 2 and 3 parallel on X and test on Y parallel
• unlock X and unlock Y

seeing as Jenkins does not allow parallel in parallel, I cant switch it to:

-build stage

• (deploy to X -> test 1,2,3 parallel lock X) and (deploy to Y -> test Y lock Y) parallel

So having the option to start the lock X after the build stage and stop after test suites for X would be ideal, which is not feasible by using the lock(X) { } wrapping because then Y is also locked for the duration of the X test suites

Reference any relevant documentation, other materials or issues/pull requests that can be used for inspiration.

No response

Are you interested in contributing to the documentation?

Not sure if it's feasible, so can't really contribute :/

[mPokornyETM]

"seeing as Jenkins does not allow parallel in parallel, I cant switch it to:"
it is not true, it is allowed, and it also works, but there are no plugins (even core) which can show it correctly

I am not pretty sure, wha you need, but in scripted pipeline you can use lock() in lock()

stage('Init') {
    echo 'hello world'
}

def stages = [:]
stages['suite1'] {
  node('windows') {
    doTest('TC-1');
    doTest('TC-2');
    doTest('TC-3');
  }
}
stages['suite2'] {
  node('debian') {
    doTest('TC-1');
    doTest('TC-2');
    doTest('TC-3');
  }
}
stages['suite2'] {
  node('RHEL') {
    doTest('TC-1');
    doTest('TC-2');
    doTest('TC-3');
  }
}

stage('Testing') {
    parallel stages;
}


void doTest(final String testCase) {
    lock('test-infra-' + testCase) {
        echo 'execute test case: ' + testCase
        sleep 60
        lock('Publish results') {
            sh 'echo "I am done ' + testCase + ' on node ' + env.NODE_NAME + '" >> /mnt/some/shared/file.txt'
        }
    }
}

• you are sure test cases are siolated (does not matter which nodes win)
• and updating the file '/mnt/some/shared/file.txt' will be synchronized (locked) over all jobs. That means only one node has access at the same time

When it is not what are you @royteeuwen looking for, pls paste here some diagram (UML) or somthing like that, to explain, what you want to reached.

[royteeuwen]

I indeed figured out in the meantime that scripted does allow parallel in parallel, it just doesnt visualise (correctly), which is a shame to be honest, it shouldn’t be difficult to visualise it correctly.

doing this approach does indeed achieve what I want, but just out of curiosity, it wasn’t an actual answar to what I was looking for, my question was rather, can i do the following in any way (scripted or not):

stage {
lock(‘label’)
do stuff
}
stage(2) {
do sture
unlock(‘label’)
}

[mPokornyETM]

The answer is easy. Currently no.
In the meaintime, there was few questions to do that like you propose, but in all cases we provide just an other working example and it was unnecessary.
Why I dont like it. It is danguerous.

• When you forgot for some reason to unlock the resource (job hard killed ...) it might happens, that it will be locked for ever.
• You can unlock a resource currently used by other build ...

in your shart example will this works

lock(‘label’) {
  stage {
    do stuff
  }
  stage(2) {
    do sture
  }
}

But I don`t think, this is waht you want

[royteeuwen]

OK, I can definitely understand why it isn't ideal to do it!

In the meantime I already decided to rewrite it to parallel in parallel, meaning that I had to drop the declarative pipeline and replace it with scripted, plus blue ocean doesn't render it correctly anymore. But puristically it's more logical for it to be parallel in parallel, so very sad Jenkins doesn't support it correctly in declarative

Thanks for the help!