Block scopes and nesting/interleaving

[tobias.gr...@gmail.com]

Hi all,

I have a (maybe stupid) design question: Many pipeline features define some kind of "block scope": (stage, node, withEnv, etc.). Most of those nest quite naturally, but sometimes, people want to break this "rigid" structure.

As a recent example there is this pull request to the lockable-resources plugin: https://github.com/jenkinsci/lockable-resources-plugin/pull/185

While I understand the desire to break the structure (locking in one stage, unlocking sometimes in a later stage), I'm hesitant to "relinquish control" of the locking-block, which nicely wraps the thing that should be locked.

Thoughts? Ideas?

Regards, Tobias

[Austin Witt]

The block is nice because through it, Jenkins enforces that the build will eventually release the lock, and it is hugely obvious when that will happen.

Allowing the "return the lock, and not require body" opens the possibility of a build acquiring a lock but failing to release it (when expected).

The fact that failing to release a lock when you meant to is "not" possible with the block design is a huge feature! Changing the behavior of the lock step would break most pipelines that currently use it and just as bad - in my opinion - force pipeline authors to correctly handle locking and releasing to avoid deadlocks, in every pipeline!

Deadlock issues aside, this is a colossal interface change for pipeline authors to understand!

With a change, everyone would have to correctly set up try/catch blocks throughout their pipeline, and handle locking/unlocking manually!

Perhaps a new step name (manualLock? getLock?) to indicate that pipelines must take explicit responsibility for managing the lock, and the original step name (lock)( ... ) { ... } ) continues to function as before? A way to extend support to cover the additional use-cases without breaking or burdening the existing use-case?

--
You received this message because you are subscribed to the Google Groups "Jenkins Pipeline Authoring SIG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkins-pipeline-auth...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkins-pipeline-authoring-sig/8efb9f14-634c-4c96-aefc-07454cce2531%40googlegroups.com.

[tobias.gr...@gmail.com]

Of course I don't want to break existing use cases, the pull request keeps the original block syntax intact, but adds new syntax omitting the block scope. Pro: Doesn't pollute pipeline with another "keyword", Contra: Maybe not that obvious - Using a new step (acquireLock?) would also work...

I agree that the block syntax is the more obvious, but there seem be a usecases in complex pipeline scripts where lock and release are in different scopes. Contrived example: Taking a lock inside a node (to prepare a server process on one node) and keeping the lock until something on another node finishes (maybe running a benchmark suite against the first node) - In this case we need to take the lock after we know on with (first) node we are running on, but we need to keep the lock until all jobs on multiple nodes are finished...