jglick are you talking about this? https://www.jenkins.io/doc/pipeline/steps/groovy/
That might be just what I was looking for - thanks for the tip, going to try that.
Let me try to explain my use case in a little more details.
My users have read-only access to my Jenkins. My automation provisions a GitHub Org Folder for their orgs, and in the folder job config I make use of the following two plugins:
https://plugins.jenkins.io/pipeline-multibranch-defaults/
https://plugins.jenkins.io/inline-pipeline/
With the help of these two plugins - for the Org Folder there is a custom marker/recognizer file instead of the Jenkinsfile (for the sake of the argument let's say it is an arbitrary yaml configuration file) along with a default hard-coded inline Jenkinsfile definition that the users cannot change. The hardcoded Jenkinsfile fetches the yaml configuration file and delegates to the global shared library. The library in turn reads the configuration file and produces a Jenkinsfile DSL text that is then being evaluated in the aforementioned hard-coded Jenkinsfile. The DSL generator library is just that - a text producing template engine. It doesn't even define steps (other than the entry point step to be called from that hardcoded Jenkinsfile). All the real steps are in other libraries, and they are not called from this DSL generator library, and they all are CPS-friendly.
As you can see - there is zero untrusted DSL code that is coming from the users. 100% of the code is trusted. Neither does this code requires CPS survivability as it is an idempotent text producer. Its execution time is seconds and even if it gets interrupted for whatever reason, it can safely be called again with the same input.
In such a setup having to deal with CPS woodoo is just that what you said 3 years ago - a waste of everyone's time. You could argue this particular shared library could be actually a plugin, which is absolute truth, but keeping it as a library adds a benefit for our users to specify a library version per repository/branch - which adds tremendous level of stability, isolation and a blast radius damage control. If it was a plugin - it would be a version shared globally across all my users.
With https://www.jenkins.io/doc/pipeline/steps/groovy/ - I wonder if all I have to do is simply wrap either call to the library step in my hardcoded Jenkisfile with that or wrap a call to the library classes from the actual library step. I am definitely going to try that.
jglick it has been been 3 years since your last comment, may I inquire what were you referring to when you said "allowing external process execution, not wasting any more time on the CPS engine" and is this something available to use? Is there any documentation on that alternative mechanism?
Unless I am missing something, I see no real alternative at the moment after 3 years of waiting. I would imagine Groovy being chosen to be the engine for its high level abstractions, meta programming features and ease one could create their own DSL. But when so fundamental features such as commonly used annotations ToString, EqualsAndHashCode, Delegate as well as Groovy Traits are not available - it is kind of defeats the purpose, doesn't it? Sometimes it is so frustrating to work on complex libraries as you may never know if your code will actually work in the CPS or not.
If not fix it, why not extend NonCPS annotation to support classes or maybe even allow users to disable it altogether for a given libraries? In certain use cases - the library forcibly injected into the pipeline and it is only limited to generating the pipeline and is not used in runtime - meaning all of the library classes are trusted and they require no survivability as the actual generated pipeline will be executed separately - in which case CPS is nothing but trouble, introducing artificial limitations for no practical gain. In my pretty complex library I have 99% of my methods annotated with NonCPS (except for the ones that are exposed to be called from Jenkinsfile context), meaning - CPS is actually only 1% efficient for my use case.
I would argue this issue has to be revisited and acted on. Unless, of course, there is a viable alternative that I am not aware of.