Azure-devops-docs: How to get previous build pipeline's build number in case of consecutive build pipelines?

[arefinsami]

Assume BuildPipeline2 gets triggered when BuildPipeline1 finishes.

BuildPipeline1->BuildPipeline2

When BuildPipeline2 is getting executed is there a way to get BuildPipeline1's build number? I am looking for something like Last.Build.BuildNumber. Os is there a way to pass the BuildPipeline1's build number to BuildPipeline2 ?
Thanks.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: dd7e0bd3-1f7d-d7b6-cc72-5ef63c31b46a
• Version Independent ID: dae87abd-b73d-9120-bcdb-6097d4b40f2a
• Content: Variables - Azure Pipelines
• Content Source: docs/pipelines/process/variables.md
• Product: devops
• GitHub Login: @andyjlewis
• Microsoft Alias: alewis

[cyberblast]

Share variables across pipelines: https://docs.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=azure-devops&tabs=yaml%2Cbatch#share-variables-across-pipelines

[arefinsami]

@cyberblast, I am not sure how this helps.

In each agent job the variables in a group get reinitialized to the original vcalue defined in the group. The updated value doesn't carry forward. So variable group is not a solution. It needs somehting like Last.Build.BuildNumber.

[cyberblast]

You can also simply write it to a file on the agent or into the repo and check it in.
Or into a separate repository - holding your variables only. Didn't know the group variables are resetting for every build. That doesn't make any sense to me - but we are not using them anyway.
We're using the "write it to the same repo and check it in" approach for automated build versioning purposes. We have a npm package.json and run a npm version command to bump the version number for that solution. After that we rewrite assemblyinfo.cs files to set AssemblyFileVersion attributes using a powershell script. Finally the updated files get checked in (without triggering a new CI build). The build, unit testing etc. starts after versioning completed.
But I'm unsure what your exact scenario looks like. However - you should be able to write any variable to a file and put that wherever you want to work with it later on.

[levenleven]

Not sure but you might be looking for Build.TriggeredBy.BuildId
https://docs.microsoft.com/en-us/azure/devops/pipelines/build/variables?view=azure-devops&tabs=yaml

[sukoneck]

Anyone figure this out? I'm in the same boat as @arefinsami

[sukoneck]

@benc-uk found the answer here. Here's how to get metadata across pipelines:

1. Define the first pipeline as a resource
2. Call that pipeline's metadata using this schema, where <alias> is the friendly identifier you defined in the pipeline resource block

Three notes that were helpful for my situation:

1. I was struggling through getting the pipeline trigger to work as expected using YAML, and still haven't. Instead, I removed the pipeline trigger (i.e. the trigger: that's within the pipeline resource block) and added a "regular" CI trigger. When you define the resources: block, the default action of a pipeline trigger is nothing- they don't run unless you explicitly specify the trigger:, which is the opposite pattern of a CI trigger which runs by default unless explicitly told trigger: none. So, this does what I want, which is to trigger the second build pipeline off of a change to a repo while also bringing in metadata from the build that changed that repo
2. The metadata that was really what I needed was the first build's Build.BuildNumber which translates to resources.pipeline.<Alias>.runName
3. Not so much helpful, but might be related to why I couldn't get the pipeline trigger to work: the YAML for both of my pipelines were colocated in the root of the same repo

[ashokirla]

Thanks for the feedback. We have plans to add support for exposing info about the resource that has triggered the pipeline. We will work on it starting next quarter.

[PaulCharlton]

there's another way ... for those who want this information in bash or shell scripts, the environment variables appear to have the following:

```

identifies upstream pipeline

RESOURCES_PIPELINE_{upstream_pipeline_name}_PIPELINEID
RESOURCES_PIPELINE_{upstream_pipeline_name}_PIPELINENAME
RESOURCES_PIPELINE_{upstream_pipeline_name}_RUNID [ {build#} ]
RESOURCES_PIPELINE_{upstream_pipeline_name}_RUNURI [ vstfs:///Build/Build/{build#} ]
RESOURCES_PIPELINE_{upstream_pipeline_name}_RUNNAME [ date.pipeline_build_iteration ]

identifies upstream repository and commit

RESOURCES_PIPELINE_{upstream_pipeline_name}_SOURCEBRANCH
RESOURCES_PIPELINE_{upstream_pipeline_name}_SOURCEPROVIDER
RESOURCES_PIPELINE_{upstream_pipeline_name}_SOURCECOMMIT

[t-l-k]

It is a shame, or so it appears, that the resources.pipeline.<Alias>.runName variable, cannot be referenced, when it appears within an expression on the RHS of the pipeline attribute name. This attribute is responsible for setting the build number.

You might imagine, that you'd want a 2nd build (CD) triggered from by a 1st build (CI), and that you'd want the the build number of the CD pipeline to closely match to the build number of the CI pipeline, perhaps with an additional sprinkling of naming metadata.

I've opened a ticket for this issue, because to me it sounds like a very reasonable use case!