-
New Feature
-
Resolution: Fixed
-
Major
Currently you must write e.g.
step([$class: 'JUnitResultArchiver', testResults: 'target/surefire-reports/*.xml'])
which is awkward. Also in Snippet Generator you need to look under General Build Step for what to a user is logically a distinct step.
Metasteps (step, wrap, checkout) should have an API by which they can declare that their delegate (scm in the last case) ought to be treated as a top-level step as far as DSL and Snippetizer are concerned, via some kind of syntactic sugar. In the absence of any Jenkins core API which would allow a Descriptor to specify a short name (yaml-project tries to define one of its own), this would have to be constructed somehow from the $class, perhaps simply:
JUnitResultArchiver testResults: 'target/surefire-reports/*.xml'
or with just one mandatory parameter even
JUnitResultArchiver 'target/surefire-reports/*.xml'
The follow-up question is what to do with nested Describable objects used in the configuration. So
GitSCM ..., extensions: [[$class: 'PruneStaleBranch']]
still looks unnatural. The Groovy builder idiom might suggest
GitSCM ..., extensions: [PruneStaleBranch {}]
though closure handling in JENKINS-26135 would need to be addressed first. Requires study to make a PoC.
- causes
-
JENKINS-63676 Unexpected behavior of pipelines, possibly due to symbol overlap
-
- Resolved
-
- depends on
-
JENKINS-45109 Metasteps fail to display the delegate symbol in console log
-
- Resolved
-
-
JENKINS-31582 Log / document the plugin usage in the flow nodes
-
- Resolved
-
- is blocked by
-
JENKINS-37215 Make HTML step reference honor metasteps
-
- In Review
-
-
JENKINS-38037 Single parameter metasteps don't work with named-parameter symbols as of workflow-cps 2.14
-
- Resolved
-
- is blocking
-
JENKINS-37227 Metastep support for checkout step
-
- Open
-
-
JENKINS-30519 Declarative job properties in multibranch
-
- Resolved
-
-
JENKINS-31247 Copyartifact: more integration with workflow
-
- Closed
-
- is related to
-
JENKINS-26126 DSLD and/or GDSL
-
- In Progress
-
-
JENKINS-35506 Add a symbol to the build step in the hpi Maven archetype
-
- Open
-
-
JENKINS-30088 Clean up step display
-
- Resolved
-
- relates to
-
JENKINS-29711 Snippet Generator: missing attribute names in single-entry forms
-
- Resolved
-
- links to
[JENKINS-29922] Promote delegates of metasteps to top-level functions, deprecate $class
Link |
New:
This issue is related to |
Link |
New:
This issue depends on |
Assignee | Original: Jesse Glick [ jglick ] | New: Kohsuke Kawaguchi [ kohsuke ] |
Summary | Original: Promote delegates of metasteps to top-level functions | New: Promote delegates of metasteps to top-level functions, deprecate $class |
Link |
New:
This issue is blocking |
Link |
New:
This issue is blocking |
Link |
Original:
This issue depends on |
Assignee | Original: Kohsuke Kawaguchi [ kohsuke ] |
kohsuke proposes introducing a plugin (or other library?) with an annotation that could specify a script-friendly name (restricted to be a Java identifier, I suppose) for a Describable; the fallback value if not annotated could be the Class.simpleName. Using an annotation rather than a method on Descriptor ensures that mechanical indexers can run without executing code. Perhaps StepDescriptor.getFunctionName should also be deprecated in favor of the new annotation.
Thus we could have something like
junit testResults: '…'
This could also be used in nested describables, using a builder pattern. Assuming annotations on GitSCM¹ & UserIdentity:
(
JENKINS-30222might need to be solved before adding support for nested describables, since we must ensure that these dynamically-generated functions are accessible not just in the sandbox but also in secondary CpsScript instances. Of course the existing technique in DSL may suffice without much work.)The builder pattern would allow us to replace $class on polymorphic (singleton or collection) properties. An open question is what, if anything, to do with monomorphic properties (usually collections). A quick recap:
So consider a monomorphic property such as GitSCM.userRemoteConfigs. We could either force it into the builder pattern as well:
or just leave it to use the map syntax as today (which we must continue to support for compatibility anyway):
¹Note that the identifier git is already taken by a custom step, so either we do not annotate GitSCM, or we use a different name, or the custom step wins and flows must use the Class.simpleName.
² Using the builder pattern also at top level, for steps, would be more consistent, but also more verbose, and perhaps incompatible:
echo {message = 'hello world'}
does not flow.