gradle(...) step for workflow is desirable, so that its output gets annotated to show the list of tasks that have been executed.
Gradle pipeline support: withGradle and ConsoleAnnotator
Add @Symbol("gradle") to Gradle's ToolDescriptor
CloudBees Internal OSS-182
CloudBees Internal OSS-2131
Having a gradle step that survives restarts/disconnections would be great eventually, but does that really need to hold up Gradle becoming a first-class build step? The manual tool/withEnv/sh approach is clunky, and I'm really missing the GradleConsoleAnnotator.
I have to agree with douglaswpaul, I would really like to use gradle plugin in the my pipeline scripts instead of the sh approach. Also, as far as I am aware, the JENKINS-26055 is a "Won't Do". So what's up now?
lorantonodi: What would you expect to be supported as part of the pipeline DSL? What are your use cases?
I would look into implementing better support for pipeline but first I would like to know what should be supported and what the DSL would look like.
This is being considered as part of the Important Pipeline Compatibility Epic. Here are the tasks to get this plugin to a basic level (not a durable task) of pipeline compatibility:
We are splitting the withGradle and ConsoleAnnotator into JENKINS-44834 and leaving this issue targetted at the original request for a gradle step. We believe that JENKINS-44834 will address the core use-cases which gradle users expect from gradle integration with pipeline.