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.
--
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
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
" 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
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