@bradrydzewski, would you consider a more general-purpose information-sharing solution? What I’m picturing is some way to “lift” values from the workspace into the pipeline context itself, probably as environment variables. This would allow the pipeline steps to refer to those values directly, rather than relying on an individual plugin to know that file-based information might be useful. For instance, to use the info in the command-line of a plugin that doesn’t have a general-purpose shell in its image, and thus can’t do any shell scripting as a precursor to the actual command.
Note that this is slightly different from [Feature Request] Setting environment variables as build steps and Pass environment variables to pipeline, because the information to be lifted is/might be generated as a byproduct of the pipeline step itself. (In my particular case, a main-line build uses
npm version patch to bump the version number to a new value, and I need that version number elsewhere.)
I haven’t yet wrapped my head around the actual step-by-step, under-the-covers process of the pipeline, but I’m hoping it would be possible to get an agent to do something like use the
Upload() RPC call to pass a
.env-style file back to the server, and then update the pipeline’s environment variables for all subsequent steps. For this to even be feasible, though, it requires that subsequent steps aren’t evaluated/expanded until after the previous steps complete. I’m pretty sure that this is, in fact, the case, though, since variables like
CI_BUILD_STATUS can change as the pipeline progresses.
If this seems like a reasonable approach, I’ll figure out a concrete proposal and work on putting a PR together.