Granularity of pipeline steps

[Ullrich Hafner]

I’m currently implementing a better pipeline support for the static analysis plug-ins (see [1]).
From the documentation of Step it is not clear to me, when to implement a Step or when to use a method on a returned object. So basically, is a procedural or object oriented approach desired?

E.g, in a freestyle project the warnings publisher does the following things (among others):
1) parse files for warnings
2) copy files to build folder for future reference
3) compute difference (new, old, fixed warnings) with regard to a reference build
4) blame authors of warnings
5) publish warnings as persistent Action

So my question is: is everything a step? Or should e.g. step 1 (parse warnings) return an object that has some methods, e.g. to copy the files (2) to the build folder?

When I implement everything as Step then the list of available steps will grow very fast (name clashes will be also very probable)

Are there some recommendations or is this decision up to the plugin author?

[1] https://wiki.jenkins.io/display/JENKINS/Static+Analysis+in+Pipelines

[Björn Pedersen]

Hi,

It looks like a lot of the problems are linked to:
https://issues.jenkins-ci.org/browse/JENKINS-28119,Link to log of failed step
https://issues.jenkins-ci.org/browse/JENKINS-38381, Optimize log handling in Pipeline and Durable Task
https://issues.jenkins-ci.org/browse/JENKINS-26522, Annotated block/stage status

Björn

[Jesse Glick]

On Mon, Jul 24, 2017 at 4:55 PM, Ullrich Hafner
<ullrich...@gmail.com> wrote:
> in a freestyle project the warnings publisher does the following things (among others):
> 1) parse files for warnings
> 2) copy files to build folder for future reference
> 3) compute difference (new, old, fixed warnings) with regard to a reference build
> 4) blame authors of warnings
> 5) publish warnings as persistent Action
>
> So my question is: is everything a step?

With the possible exception of #4, all of these sound like they should
be part of a single `Step`. (Or if the freestyle version can
reasonably be factored into a `SimpleBuildStep`, there is no need for
a `workflow-step-api` dependency at all.) Compare
`JUnitResultArchiver`.

If you do need to break functionality apart in order to offer greater
flexibility, just provide multiple steps. OO style is not well
supported.