• Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      I wanted to break my pipelines into steps (including parallel) but each step runs separately and env variables are not shared between them, so 3 steps that configure them has to be repeated for each step right now.

      I'd like to have a way to specify that i want to keep env variables from previous step just like we keep files using "artifacts".

            [BCLOUD-15849] Ability to pass environment variables to later steps

            Pinned comments

            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

            Edmund Munday added a comment - 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

            All comments

            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

            Edmund Munday added a comment - 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.

            Edmund Munday added a comment - 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.

            Ian Klek added a comment - - edited

            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

            Ian Klek added a comment - - edited 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

            Jason Harrison added a comment - - edited

            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.

            Jason Harrison added a comment - - edited 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.

            Matt Ryall added a comment -

            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.

            Matt Ryall added a comment - 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.

            Matt Ryall added a comment -

            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.

            Matt Ryall added a comment - 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.

              57465700c4e1 Edmund Munday
              4dd9caa24881 Vitalik Zaidman
              Votes:
              107 Vote for this issue
              Watchers:
              41 Start watching this issue

                Created:
                Updated: