https://www.atlassian.com/blog/bitbucket/easily-share-data-between-steps-in-bitbucket-pipelines  "Security: This feature is not intended for sharing secrets. " - sadly that's what we want it for, would be nice to have more security around passing tokens between our login step and our condiditional sub-build steps.  The implementation is just writing a script file dynamically and they auto-run the script file, it saves 1 line of code and doesn't add to the security of the existing method of sharing data between steps by writing artifacts to file.

Hi everyone - we're excited to announce our new Variable Sharing feature, designed to make it significantly more simple to share context and data between the steps in your Pipeline.

This feature will also form the foundation for future functionality designed to enable more powerful conditional logic on steps in Pipelines.

For more information on how to take advantage of this new feature, check out the launch blog here: https://www.atlassian.com/blog/bitbucket/easily-share-data-between-steps-in-bitbucket-pipelines

Hi all - this is currently in development and we will share more information closer to release.

We have opened an RFC in the Pipelines Community space - we would greatly appreciate if you could take the time to review and provide comments: https://community.atlassian.com/t5/Pipelines-articles/Request-for-Comment-RFC-Step-level-Variable-Sharing/ba-p/2933210#M35

We are planning to deliver this capability in the next 3-4 months. It will be implemented in the form of a kind of "Pipeline level state object" that steps will be able to read/write to/from.

This same state object will also be exposed to step "conditions" along with a basic expression syntax to implement conditional execution on steps.

We believe this implementation will allow us to solve multiple overlapping customer challenges with a single set of capabilities.

Please Atlassian, so many tickets here can be solved by a single solution, so you should aggregate the votes and realise that there'a a big demand.

E.g. is this not similar? https://jira.atlassian.com/browse/BCLOUD-17453

Heck, you probably could have killed off the ticket with the most votes simply by allowing the setting of global environment variables! (https://jira.atlassian.com/browse/BCLOUD-18261)

One more for you https://jira.atlassian.com/browse/BCLOUD-20821

I'm breaking my pipeline into separate steps and even separate branches. Without the ability to specify the same deployment for more than one step I have to copy the deployment definitions. An artifact would not work in this case.

I haven't tried YAML anchors yet as  workaround.

This issue came up in a discussion via email with a customer.

In their situation, they would like to capture a version number and pass it to a later manual step, which would retrieve the tagged artifact and deploy it. These artifacts are stored indefinitely, so they would like to be able to do this even after the current 7-day limit on artifacts, which the above workaround won't help with. So we'd want to make sure that environment variables are stored in a way that we can keep them around indefinitely.

Interesting idea. Can you (or the other voters/watchers on this ticket) provide a specific example of something you want to pass between steps? Is it a version number or similar?

If the values are static, you could configure them as an environment variable in your Pipelines configuration (via repository Settings > Pipelines > Environment variables), they will be available to each step in your pipeline.

Obviously that won't work for values which come dynamically from your build, which is why I'm curious what exactly you want to pass through.

Probably the best workaround for now is to write the values to a file, pass that file as an artifact, and source the file in the next step. Something like this:

pipelines:   default:     - step:          script:            - echo export VERSION=`generate-version.sh` >> build.env
         artifacts:            - build.env
    - step:          script:            - source build.env
           - echo "Building ${VERSION}..."

I just tested this out, and it works reasonably well. Hopefully a good workaround until we can find time to add something more specific.