Great question @eliot_pear!
There are two things worth to discuss here:
- How to expose a list of outputs from a Step, and consume that in other steps
- How to run the same step multiple times, and have access to the output of all the same steps, instead of overwriting each others
How to expose a list of outputs from a Step
For the first point we think this should be the official way to do it: https://github.com/bitrise-io/bitrise/blob/master/_docs/step-development-guideline.md#inputs-which-can-accept-a-list-of-values
You should postfix the input ID with
input_path_list), and expect the values to be provided as a pipe character separated list (e.g.
first value|second value)
We’ll soon start to test this solution through our core steps, so far this solution seems to be the best way to handle lists of outputs, e.g. if a Gradle Runner step generates more than one
How to reference outputs of separate steps which expose outputs with the same environment variable key
The solution for this right now, which works but not exactly a clean solution, is to use a Script step, right after the step which generated the output which would be overwritten later, and in the Script step “copy” the value to a new environment variable. Docs: http://devcenter.bitrise.io/tips-and-tricks/expose-environment-variable/#copy-an-environment-variable-to-another-key
This could be released as a new step too, see: [Step] "bridge" an environment variable - assign the value of one Step's output to another Environment Variable
What we plan to do, is to add this as a built in feature in the Bitrise CLI / bitrise.yml . In short, you could do something like what you described:
but instead of doing any
eval hack, and hopefully without making this “misleading”, we’d propose a new item/syntax for step outputs. In
bitrise.yml right now you can’t overwrite outputs (it makes sense, as you can’t change how a step generates an output), but we would add an “alias” or “name” syntax, so that you could define an alternative name for the environment variable.
- GIT_CLONE_COMMIT_HASH: SAVE_IT_INTO_THIS_ENV_VAR
This would indicate for the Bitrise CLI that you want to store the
GIT_CLONE_COMMIT_HASH output of the Git Clone step into the
SAVE_IT_INTO_THIS_ENV_VAR environment variable, instead of into
GIT_CLONE_COMMIT_HASH. Of course if you don’t provide an output item for the step, then
GIT_CLONE_COMMIT_HASH will be generated and it won’t be modified, like the way it works today.
This would be a pretty similar solution to what I described above as “The solution for this right now”, but built into the Bitrise CLI and into the
bitrise.yml format specs, so that you don’t have to use a separate step for this.
Whether this is a copy or a rename of the
GIT_CLONE_COMMIT_HASH env var is still up for discussion (whether
GIT_CLONE_COMMIT_HASH should still be populated in this case, or only
SAVE_IT_INTO_THIS_ENV_VAR). Personally I think “rename” should be enough, if you define an alternative name there’s no need to keep the value in the original output as well.