Hi all - this is the first RFC we've done via this community, but we'd like to make this a regular thing depending on how engagement goes with this attempt.
This RFC is to gather ideas/feedback on our implementation for Step-level Variable Sharing. A new feature coming soon to Pipelines.
Summary
This feature will allow users to share environment variables between steps. A variable can be defined in one step, and subsequent steps in the same pipeline will have access to that variable.
Motivation
Currently, there is no standard way to achieve this. There are workarounds available, the one most often used is to save variables in an artifact file, and use that artifact in subsequent steps to set variables. This is a functional solution, but not recommended because
-
It involves custom logic that is not using artifacts for their intended purpose
-
It’s annoying and non-intuitive for customers to use this approach
-
Variables produced this way can easily override other variables when they maybe should not
Example Usage
Users can save variables to a step-level variable object. At completion of the step, these variables are extracted and saved as pipeline-level variables, which are imported into subsequent steps.
step:
script:
echo "MY_VARIABLE=some_value" >> $BITBUCKET_STEP_VARIABLES
Key Points:
- Variables produced by a step are saved as generic pipeline-level variables. They will be injected into all subsequent steps using the variable name defined when they were created initially.
- If multiple steps write to the same variable name, the system will follow a "last write wins" strategy.
- Variables will be captured by the system at the end of each step, not at the point when the variable is written in the script.
- Variables will be injected into steps when the step starts and will not be updated (in the context of the running step) if the value of the variable (at the pipeline level) changes during a steps execution.
- This avoids instability due to race-conditions between steps causing variable values to change mid-step.
- The current state of all pipeline-level variables will be printed to the step setup logs when each step starts. This will provide users with an immutable record of the state of all variables for each specific step.
Key Questions:
- What level of priority should be given to step-level variables if they are written with the same name as Workspace/Repo/Environment/Custom variables?
- e.g. Should variables captured from a step take highest priority, leaving pre-set variables to act more like "fallback values"?
