Output from multiple instances of the same step

Development Step Dev
2

Great question @eliot_pear!

There are two things worth to discuss here:

  1. How to expose a list of outputs from a Step, and consume that in other steps
  2. 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

TL;DR;

You should postfix the input ID with _list (e.g. 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 .apk file.

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: Environment Variables - Bitrise Docs

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.

E.g.:

- git-clone:
    inputs: []
    outputs:
    - 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.

WDYT @eliot_pear?

1 Like