For teams using Bitbucket Pipelines, Atlassian has rolled out a powerful new feature: the ability to share variables between parent and child pipelines. This enhancement unlocks a new level of flexibility in continuous integration and delivery workflows. It allows a parent pipeline to pass information directly to a child pipeline when it triggers it, something that was not possible before.
Bitbucket’s parent/child pipeline functionality was introduced earlier in 2025. It allowed one pipeline to trigger another as a separate unit, helping to break large CI/CD processes into smaller parts. However, until now there was no straightforward way for a parent pipeline to pass along context or data to its child. Teams often resorted to workarounds. For example, they might use repository-level variables or generate artifact files just to transfer a value from one pipeline to another. The new variable-sharing feature bridges this gap by enabling you to define and send variables from a parent to a child pipeline seamlessly.
Enhanced workflow orchestration: Passing variables means a parent pipeline can hand over important context such as configuration flags, environment names, or artifact identifiers to a child pipeline. This makes it possible to create more sophisticated and conditional workflows without manual intervention.
More modular pipelines: Variable sharing encourages a modular pipeline design. You can split a complex process into separate pipelines and still have them work together seamlessly. For example, a primary build pipeline could trigger a separate deployment pipeline and pass along the necessary details. Each pipeline performs its specialized task with the data it needs from the parent, resulting in cleaner and more maintainable configurations.
Reduced workarounds and hacks: Before this feature, teams had to get creative to share data between pipelines, often using global variables or writing data to temporary files. Now the mechanism is built-in. This reduces complexity and potential errors, since you no longer need to maintain brittle scripts or workarounds just to pass information around.
Improved efficiency: Being able to pass up to 20 variables into a child pipeline call means you can transmit all necessary data in one go. This minimizes the need for re-fetching data or recomputing values in the child pipeline, saving time and build minutes. It also allows child pipelines to start with the exact context they need, which can speed up execution and make the overall process more efficient.
Now that we understand the benefits of this feature, how do you actually set it up? In the steps below, we outline the configuration process for enabling parent-child pipeline variable sharing in Bitbucket Pipelines. It only takes a few straightforward additions to your pipeline YAML file to get started.
Define variables in the parent pipeline: In your bitbucket-pipelines.yml file, start by declaring any variables you want to pass to the child. Under the parent pipeline's definition, add a variables section. For each variable, give it a name and a default value. You can also specify a list of allowed values to restrict what can be passed. We'll discuss allowed values in more detail shortly. For example, you might define a variable named parent_pipeline_variable with a default value "value_1", and allow only "value_1" or "value_2" as the permitted options.
Invoke the child pipeline with input variables: Next, within the parent pipeline step that triggers the child pipeline, include an input-variables mapping. This is where you hand off values to the child. Map each child pipeline variable name to a value or variable from the parent side. For instance, if your parent pipeline has a variable called parent_pipeline_variable, you could pass it to the child as var_1: $parent_pipeline_variable. You can do the same for other types of data. For example, pass a repository-level variable by referencing it (var_2: $REPOSITORY_VAR_NAME), or pass a fixed string literal (var_3: "static-value"). Each entry under input-variables becomes available in the child pipeline as an environment variable.
Use the variables in the child pipeline: In the child pipeline’s definition and steps, you can now use the values that were passed down. The child pipeline will receive each input as a pipeline variable named exactly as you specified (like var_1, var_2, etc.). Inside the child pipeline’s steps, you can reference these just like any other variable (for example, using $var_1 in a script to access its value). If needed, you can also define expected input variables in the child pipeline's YAML under a variables section to set defaults or enforce allowed values on the child side.
One useful control that comes with this feature is the ability to restrict variable inputs to a defined set. By using the allowed-values setting, you can ensure that only expected values are passed from the parent to the child pipeline. In the parent pipeline's YAML, when defining a variable, you can list specific values that are permitted for that variable. The pipeline will then only accept those values when it runs. This is great for preventing mistakes. For instance, imagine you have a variable for the deployment environment that should only ever be "staging" or "production". If you declare those two options as the only allowed values, the parent pipeline cannot be executed with any other value for that variable. This eliminates the risk of a typo or unsupported environment name being passed down to the child.
Allowed values can also be specified in the child pipeline's configuration. In the child pipeline definition, you might declare an expected input variable along with the allowed options it can take. That way, even if the parent attempts to pass an out-of-range value, the child pipeline will catch it and refuse to proceed. Applying allowed-values on both the parent and child sides helps to enforce consistency. It effectively creates a contract between the two pipelines about what input values are considered valid.
Security: This feature is not designed for sharing secrets or credentials. Any variables passed from parent to child will be logged in plain text in the build logs. In other words, if you were to pass a password or API key this way, it would become visible in the logs. Avoid using this mechanism for sensitive information.
Limits: You can define at most 20 input variables in a single parent pipeline step that triggers a child pipeline. This is a hard limit set by Bitbucket. In practice, 20 variables should be plenty for most scenarios, but it's something to keep in mind if you plan to pass a large amount of data.
Validation: The usual Bitbucket Pipelines naming rules for variables still apply. Variable names must use only letters, numbers, or underscores, and they cannot begin with a number. Additionally, the values assigned must be either static strings or references to existing variables using the $VAR_NAME syntax. If you violate these rules, the pipeline configuration will not be considered valid.
Variable-sharing between parent and child pipelines is a significant step forward in making Bitbucket Pipelines more flexible and powerful. It closes a long-standing gap by allowing different parts of your CI/CD process to communicate and coordinate with each other. By using this feature carefully and keeping the above limitations in mind, teams can create more streamlined, modular, and efficient pipelines. Whether you want to pass along build artifacts, configuration flags, or environment information, this new capability opens the door to cleaner and more dynamic workflows.