Replacment for getBuilders()

[fkp...@gmail.com]

Hi,
In our plugin we use the getBuilders method in order to learn which builders were active during the build and get their working files and etc.
As far as i understand - moving to pipeline has disabled it due to design logic (one cannot simply know what went on during the build :) ) and  so I'm looking for better solution.

Has anyone found nice workaround which doesn't involve ugly parameter passing?

I've been thinking on simply searching for specific result files each run but I'm not sure its the best one.


Thanks ahead.

[Jesse Glick]

On Tue, Oct 18, 2016 at 9:20 AM, <fkp...@gmail.com> wrote:
> Has anyone found nice workaround which doesn't involve ugly parameter
> passing?

What exactly needs to be worked around? Each step should be
self-contained. If it needs to be told where to look for files, tell
it.

[fkp...@gmail.com]

Thanks,
well I've seen many recorders that relay on getting the builders list in order to retrieve their result file (for example - getResultFileName). Especially in large plugins they might have several outcomes of result files with unique name that's generated during the build.

I understand the design that led for self containment in builders - but in recorders, I do think that we should be able to look upon the steps so far so we can record their results more easily by getting the correct paths and data. (Are their any Jira discussions on this design that I'm missing that will shed some light?)

I prefer that the recorder won't search the different nodes for the created files - as it will also have be an issue with multi slave pipelines, a recorder that set to gather the results and parse them will need to go through each slave (i.e. every workspace - if it even possible...). So it leaves us with the choice to combine both steps instead of separating them as in freestyle build.


Or am I missing something?

[Jesse Glick]

On Wed, Oct 19, 2016 at 3:45 AM, <fkp...@gmail.com> wrote:
> in
> recorders, I do think that we should be able to look upon the steps so far
> so we can record their results more easily by getting the correct paths and
> data

If the paths were passed as configuration to the “builder”, then you
just pass the same argument to the “recorder”. (Pipeline makes no
distinction between types of build steps: you run what you want, when
you want.) If the path is somehow autogenerated, the builder could
return a value to be passed later to the recorder. Of course if there
is no particular reason for the two functions to be separated in time
then they can simply be packed into a single step.

[Fima]

" If the path is somehow autogenerated, the builder could
return a value to be passed later to the recorder."

Do you mean that the pipeline step should return result Into the pipeline code? And than pass as a parameter for the recorder ? Or should somehow save it in the build .

The recorder needs to be separated since it needs to record several different builders and it might nit be needed at a6

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/KTvwke0Maqw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3aLiA7Bh16J5zA6oWySf20k_FM8DqvfVy4Dfeho_cYgQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Jesse Glick]

On Wed, Oct 19, 2016 at 8:05 PM, Fima <fkp...@gmail.com> wrote:
> Do you mean that the pipeline step should return result Into the pipeline
> code? And than pass as a parameter for the recorder ?

That is one option, yes.

[fkp...@gmail.com]

how about job property? how you'd advise to implement it?

[Jesse Glick]

On Fri, Oct 21, 2016 at 10:59 AM, <fkp...@gmail.com> wrote:
> how about job property?

Seems like a poor approach.

My recommendation is KISS: if there is some information produced by a
step which another step call might need, just return it and let the
script bind it to a local variable.