On Fri, Oct 21, 2016 at 10:59 AM, 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.
--
You received this mes
how about job property? how you'd advise to implement it?
On Thursday, October 20, 2016 at 3:27:10 PM UTC+3, Jesse Glick wrote:
>
> On Wed, Oct 19, 2016 at 8:05 PM, Fima >
> wrote:
> > Do you mean that the pipeline step should return result Into the
> pipeline
> > code? And than pass as a para
On Wed, Oct 19, 2016 at 8:05 PM, Fima 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.
--
You received this message because you are subscribed to the Google Groups
"Jenkins Develo
" 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
On Wed, Oct 19, 2016 at 3:45 AM, 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 a
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
On Tue, Oct 18, 2016 at 9:20 AM, 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.
--
You received this message because y