Azure-pipelines-tasks: Expose Pull Request Branch name as a variable

Created on 28 Jul 2016  ·  60Comments  ·  Source: microsoft/azure-pipelines-tasks

Hi,

Not sure if it's the right place to post this request but:
Could you expose the branch associated with the pull request when it's a build made for a pull request.
Currently, all we have is

BUILD_SOURCEBRANCH = refs/pull/909/merge
BUILD_SOURCEBRANCHNAME = merge
BUILD_SOURCEVERSIONMESSAGE = Merge pull request 909 from dev/myDevBranch into master

What would be great would be a variable containing only dev/myDevBranch

Thank you

Release enhancement

Most helpful comment

Hello there @chrispat and others.

Any chances System.PullRequest.SourceBranchName and System.PullRequest.TargetBranchName variable will be added in foreseeable future? We now have only System.PullRequest.SourceBranch and System.PullRequest.TargetBranch. That is not a breaking change and the implementation could be just copied from how Build.SourceBranch and Build.SourceBranchName.

This may have not THAT many user upvotes on the one side, but on the other side it's so simple and making the API monotonous and predictable. I would do it myself and send a pull request, if that was possible.

I searched at "Use predefined variables" docs and it looks like there are no other 'Branch' variables that may require any changes. Just System.PullRequest.SourceBranchName and System.PullRequest.TargetBranchName to match with Build.SourceBranchName.

| Variable | Expected | Now |
|-|:-:|:-:|
| Build.SourceBranch | refs/heads/release/0.2.0 | refs/heads/release/0.2.0 |
| Build.SourceBranchName | 0.2.0 | 0.2.0 |
| System.PullRequest.SourceBranch | refs/heads/release/0.2.0 | refs/heads/release/0.2.0 |
| System.PullRequest.SourceBranchName | 0.2.0 | X |
| System.PullRequest.TargetBranch | refs/heads/master | refs/heads/master |
| System.PullRequest.TargetBranchName | master | X |

All 60 comments

I recommend the following when a pull request is being merged into master:

Build.TargetBranch - /refs/heads/master
Build.TargetBranchName - master

As a side note, Travis-CI currently exposes pull requests differently, as:

TRAVIS_PULL_REQUEST is set to the pull request number if the current job is a pull request build, or false if it’s not.
TRAVIS_BRANCH: For builds not triggered by a pull request this is the name of the branch currently being built; whereas for builds triggered by a pull request this is the name of the branch targeted by the pull request (in many cases this will be master).

So perhaps just overriding the Build.SourceBranch and Build.SourceBranchName would suffice with a separate variable being introduced specifically for pull requests -- which makes detecting pull requests in build scripts easier.

After re-reading, my request is slightly different from the original poster, in that he wants the actual source branch from which the pull request originated, whereas I want the actual target branch.

Travis exposes the original posters' request as:

TRAVIS_PULL_REQUEST_BRANCH: If the current job is a pull request, the name of the branch from which the PR originated. "" if the current job is a push build.
TRAVIS_PULL_REQUEST_SHA: If the current job is a pull request, the commit SHA of the HEAD commit of the PR. If it is a push build, "".

Yep, something like BUILD_SOURCEPARENTPULLREQUESTBRANCH = refs/feature/OneNewFeature

@scottdallamura ??

Missing this is starting to hurt a bit -- any plans to implement it? I am more interested in knowing the target branch of the PR than I am the source branch; but both would be nice to have.

let's fix this for QU2

You rock!

Can we have the number as well? [Whether we are doing something wrong is another question], but there is a TeamCity hook does the build process, and pulls the branch with the PR number, so I had to regex to take the number out to query TC api to get the result..

BUILD_SOURCEBRANCH : refs/pull/3436/merge
BUILD_SOURCEBRANCHNAME : merge
BUILD_SOURCESDIRECTORY : C:\agent\_work\1\s
BUILD_SOURCEVERSION : 7fec376cdxxyy72e13362yyxxbf3943b2d51e06 
BUILD_SOURCEVERSIONAUTHOR : abc
BUILD_SOURCEVERSIONMESSAGE : Merge pull request 3436 from team/bug/featureAbugs into dev

@ebrucucen yes we are adding:

system.pullRequest.pullRequestId
system.pullRequest.sourceBranch
system.pullRequest.targetBranch

note, env vars will be uppercase and dots replaced with underscore.

we're in the process of getting this change out to vsts right now. it should land in production on all scale units over the next couple days.

@tomap @dmccaffery are you using TFS or VSTS?

@ericsciple I am using VSTS. :)

Closing since this is in the process of rolling out

Same for me, on VSTS. Will check as soon as they are available :)
Thank you

i think the deployment has reached all accounts. i just checked my personal account and it is there.

Can anyone answer why BUILD_SOURCEVERSIONMESSAGE is not available when pulling from bitbucket via VSTS?

Here is my question in detail
https://stackoverflow.com/questions/45852685/vsts-missing-certain-build-flag-envbuild-sourceversionmessage

@rolandh: The feature is only available for VSTS repos. We are working on adding it to GitHub and BitBucket.

Thanks for the reply. Be great if that could be added as a side note in the list of environmental variables on the msdn.microsoft.com.

@rolandh : We will be updating the docs soon. Thank you!

@madhurig when will the docs be updated?

I tried using the variable in my branch name but it doesn't work, my branch name just looks like this:

* Branch-merge-$(System_PullRequest_SourceBranch)-20171006-01*

Here are the formats I've tried:

  1. $(System_PullRequest_SourceBranch)
  2. $(System.PullRequest.SourceBranch)
  3. $(PullRequest.SourceBranch)
  4. $(PullRequest_SourceBranch)

@mydiemho : The variables set during PR builds for repositories in VSTS are:
SYSTEM_PULLREQUEST_PULLREQUESTID
SYSTEM_PULLREQUEST_SOURCEBRANCH
SYSTEM_PULLREQUEST_TARGETBRANCH

The same variables will be available for GitHub repositories after Oct 23 (approx) in VSTS. The same work for BitBucket is on our backlog.

Thanks,
Madhuri

@madhurig that also didn't work. I'm in the same boat as mydiemho, I've tried the above combinations. I just tried $(SYSTEM_PULLREQUEST_SOURCEBRANCH) and it didn't work. For clarification, I'm doing this in the "Build number format" field under Options when editing the build definition.

$(SYSTEM_PULLREQUEST_SOURCEBRANCH)_$(Date:yyyyMMdd)$(Rev:.r) gives me
$(SYSTEM_PULLREQUEST_SOURCEBRANCH)_20171010.1

I am not sure what variables are available for build number formatting vs at build runtime. The PR variables are available at build runtime. @vijayma or @chrisrpatterson will know.

These variables are only available in the agent and cannot be used in the build number format.

So is there any possible way to get the PR source branch name into a build? Seems like the best way to name them.

You can add a PS task to set the build number as you run the build. The PS command is:

vso[build.updatebuildnumber]$(yourbuildnumber)

https://github.com/Microsoft/vsts-tasks/blob/master/docs/authoring/commands.md
Since you are running this in the agent, you have access to all variables.

Documentation for available variables is at: https://docs.microsoft.com/en-us/vsts/build-release/concepts/definitions/build/variables.

Thanks,
Madhuri

@vijayma I tried your suggestion and it did update the build number but it also return an error and break the build.

Here's the exact code I have

echo "##vso[build.updatebuildnumber] control_otter_${SYSTEM_PULLREQUEST_PULLREQUESTID}"
2017-11-07T01:51:37.3651830Z ##[error]TF209010: The build number format  control_otter_${SYSTEM_PULLREQUEST_PULLREQUESTID}" contains invalid character(s), is too long, or ends with '.'. The maximum length of a build number is 255 characters. Characters which are not allowed include '"', '/', ':', '<', '>', '\', '|', '?', '@', and '*'.
2017-11-07T01:51:37.3738400Z ##[section]Async Command Start: Update Build Number
2017-11-07T01:51:37.3759010Z ##[section]Async Command End: Update Build Number
2017-11-07T01:51:37.3825780Z ##[error]TF209010: The build number format  control_otter_${SYSTEM_PULLREQUEST_PULLREQUESTID}"' contains invalid character(s), is too long, or ends with '.'. The maximum length of a build number is 255 characters. Characters which are not allowed include '"', '/', ':', '<', '>', '\', '|', '?', '@', and '*'.
2017-11-07T01:51:37.3880310Z ##[section]Async Command Start: Update Build Number
2017-11-07T01:51:37.4577550Z Update build number to  control_otter_1088 for build 129124

Try the following:
echo "##vso[build.updatebuildnumber]control_otter_$Env:SYSTEM_PULLREQUEST_PULLREQUESTID"
That works for me.

@vijayma thanks but I'm running on linux agent so that won't work. I did figure out it's because VSTS is trying to parse the string because shell++ has a chance to resolve the variable. The solution is just to break up the string so it doesn't have the full command

VSTS_COMMAND="vso[build.updatebuildnumber]"
echo "##${VSTS_COMMAND} control_otter_${SYSTEM_PULLREQUEST_PULLREQUESTID}"

On the other hand, do you know if there's a similar command for updating release name?

Hey @madhurig was SYSTEM_PULLREQUEST_TARGETBRANCH deployed to github support too already ?

Hi @madhurig, I'm trying to use SYSTEM_PULLREQUEST_PULLREQUESTID for a GitHub repo, and the value looks strange: 171887888 while on GitHub the pullrequest ID is "1". Is it some kind of internal id?

EDIT: sorry, I found the answer, this is the GitHub internal PR ID.

Hi @henryju: We identified the same issue and are working on a fix for it.

@madhurig cool, BTW I created a dedicated issue: #6564

The right variable to use is SYSTEM_PULLREQUEST_PULLREQUESTNUMBER. We will update the docs.

Thanks,
Madhuri

We are looking for something similar to the original request (the original branch of the PR not refs/pulls/{id}/merge as a variable) but we'd like this exposed in the release, not just build. Is this possible? This would only be for the primary build artifact in the release.

Reopening the issue so that we can track it for release.

We are using PR triggers in release mode to upload our artifacts to a test area.

It would extremely helpful to have the Id of the PR available in the release pipeline, so that we can send a message to testers with a link that includes where to see the actual changes.

thanks

I second @jsancho 's request. We would like to use the Id of the PR to provision environments so it is visually coupled to the PR.

The parameters (especially System.PullRequest.TargetBranch) related to a pull request build validation step disappear when you try to kick off a failed build from a pull request validation step.

This is confusing since to create a "build validation" step, you can't use the re-queue button in the upper right of the failed build. You have to go back to the PR and rekick it off there.

Can anyone please help me how I get the Source Branch Name for using it inside the BuildFormatNumber? $(System.PullRequest.SourceBranch) is yielding "ref/heads/myPRBranch" which when used for the Build Format Number throws an error when I request a build saying it contains invalid strings. I' looking for a variable that just returns "myPRBranch". Thanks in advance.

Hello,

Sorry, but I could not understand very well... Is there a environment variable that permits I get the pull-request title? If yes, please, let me know...

Thanks

Hello,

No, there is currently a variable called $(System.PullRequest.SourceBranch) which returns a path to the source branch in this format “/ref/heads/SomeFeatureBranch”. I cant use this variable in the Build Format Number because (1) $(System.PullRequest.SourceBranch) contains slashes (2) I’m only looking for the last component i.e. “SomeFeatureBranch”.

Bala

From: Eduardo Santi [mailto:[email protected]]
Sent: Thursday, September 05, 2019 3:45 AM
To: microsoft/azure-pipelines-tasks azure-pipelines-tasks@noreply.github.com
Cc: bprodduturi bala_prodduturi@hotmail.com; Mention mention@noreply.github.com
Subject: Re: [microsoft/azure-pipelines-tasks] Expose Pull Request Branch name as a variable (#2147)

Hello,

Sorry, but I could not understand very well... Is there a environment variable that permits I get the pull-request title? If yes, please, let me know...

Thanks


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/azure-pipelines-tasks/issues/2147?email_source=notifications&email_token=AD4R5LIDAVBY5JFE5JQ4YYLQIDBHZA5CNFSM4CK4KITKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD56K2HY#issuecomment-528264479, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AD4R5LICIGCHLIMCRXO7HR3QIDBHZANCNFSM4CK4KITA.

@bprodduturi see this thread: #8793 (comment)

Hey @ustun, thank you, can you please describe how one can apply your bash script to to an Build definition? Currently I'm using "$(BuildDefinitionName)_$(Date:yyyyMMdd)$(Rev:.r)" in the BuildNumberFormat field, but I want the actual branch name (only the branch name, without dots, slashes, etc.) from the PR.

Hi @bprodduturi you need to add it as a build step (as an inline Bash script), preferable the first step.

If you echo some special outputs in a bash scripts (for example if a line starts with ##vso as in here: https://gist.github.com/ustun/b14dc73d03dca3cf1319a08ee1772120#file-azure_devops_update_build_number-sh-L31 ) , Azure Devops treats them as commands. See https://github.com/microsoft/azure-pipelines-tasks/blob/master/docs/authoring/commands.md

When a build is running, you will see that initially it will have the name as specified by "$(BuildDefinitionName)_$(Date:yyyyMMdd)$(Rev:.r)" but after this task runs, the build name is updated.

@ustun There are cases when adding your bash script as first step doesn't help. For example we're using the Environments feature where the environment resource (e.g. bookings in the link) can only come from a pipeline (root) level variable. We're using branch name as the environment resource and in that case it would be really useful to have a property like System.PullRequest.SourceBranchName

Would it be possible to add some working examples in documentation? I can't make any of the system variables work in bash based on what's currently published.

It's not clear here, and I see the question asked, is it possible to access the Pull Request TITLE from the pipelines?

We need this for Standards Validation.

@chrispat why this has been closed?

https://docs.microsoft.com/en-us/azure/devops/pipelines/build/variables?view=azure-devops&tabs=yaml#system-variables

System.PullRequest.IsFork | If the pull request is from a fork of the repository, this variable is set to True. Otherwise, it is set to False. | Yes
-- | -- | --
System.PullRequest.PullRequestId | The ID of the pull request that caused this build. For example: 17. (This variable is initialized only if the build ran because of a Git PR affected by a branch policy.) | No
System.PullRequest.PullRequestNumber | The number of the pull request that caused this build. This variable is populated for pull requests from GitHub which have a different pull request ID and pull request number. | No
System.PullRequest.SourceBranch | The branch that is being reviewed in a pull request. For example: refs/heads/users/raisa/new-feature. (This variable is initialized only if the build ran because of a Git PR affected by a branch policy.) | No
System.PullRequest.SourceRepositoryURI | The URL to the repo that contains the pull request. For example: https://dev.azure.com/ouraccount/_git/OurProject. (This variable is initialized only if the build ran because of a Azure Repos Git PR affected by a branch policy. It is not initialized for GitHub PRs.) | No
System.PullRequest.TargetBranch | The branch that is the target of a pull request. For example: refs/heads/master. This variable is initialized only if the build ran because of a Git PR affected by a branch policy. | No

Is it possible to modify $(System.PullRequest.SourceBranch) variable prior using as container image tag? Otherwise there is no use for it my case (and seems same for others).

Hi @chrispat , none of those expose the pull request Title.

FWIW, for a _PR release pipeline_ using artifacts from a _PR build pipeline_, a similar issue occurs. On inspection, at least of today, the variable BUILD_PULLREQUEST_SOURCEBRANCHNAME will be correct (i.e. the PR's branch name, not "merge").

I _think_ the difference in name is due to System.PullRequest.SourceBranch being passed along to the release pipeline.

Why so many things on Azure DevOps is very complicated and at the same time there is no support for basic things like manual jobs?
The current state of Azure DevOps is something like infamous IE6 with hacks, mysterious UIX, bugs, and half baked features everywhere (but at least some guys from Microsoft board can say - we have cloud DevOps service, too, yiiihaah). Does it really need to be as a forgotten cousin for Azure Cloud Computing Services? I'm sorry to say that.

We want to be able to build a docker image with a unique branch tag, use it in test steps, and deploy to QA environments. In Azure DevOps this is too much to ask.
You can have either have this functionality within a branch pipeline or PR pipeline, but not both, as $(Build.SourceBranchName) is always merge for PR pipeline. I can't imagine a single reason why $(Build.SourceBranchName) must be a magical merge as PR always has a source branch.

One more time, @chrispat why this issue has been closed?

Hello there @chrispat and others.

Any chances System.PullRequest.SourceBranchName and System.PullRequest.TargetBranchName variable will be added in foreseeable future? We now have only System.PullRequest.SourceBranch and System.PullRequest.TargetBranch. That is not a breaking change and the implementation could be just copied from how Build.SourceBranch and Build.SourceBranchName.

This may have not THAT many user upvotes on the one side, but on the other side it's so simple and making the API monotonous and predictable. I would do it myself and send a pull request, if that was possible.

I searched at "Use predefined variables" docs and it looks like there are no other 'Branch' variables that may require any changes. Just System.PullRequest.SourceBranchName and System.PullRequest.TargetBranchName to match with Build.SourceBranchName.

| Variable | Expected | Now |
|-|:-:|:-:|
| Build.SourceBranch | refs/heads/release/0.2.0 | refs/heads/release/0.2.0 |
| Build.SourceBranchName | 0.2.0 | 0.2.0 |
| System.PullRequest.SourceBranch | refs/heads/release/0.2.0 | refs/heads/release/0.2.0 |
| System.PullRequest.SourceBranchName | 0.2.0 | X |
| System.PullRequest.TargetBranch | refs/heads/master | refs/heads/master |
| System.PullRequest.TargetBranchName | master | X |

@syedhassaanahmed I apologize if I ask too much, but as a member of the Microsoft organization, could you please affect on the consideration of this issue? There really isn’t much work to be done, especially when considering that there is a made example on Build.SourceBranchName.

I'm trying to use these variables in a build pipeline for a github repo.

  • system.pullRequest.TargetBranch is not defined
  • System.PullRequest.TargetBranch is not defined
  • SYSTEM_PULLREQUEST_TARGETBRANCH returns the branch name develop rather than the ref, e.g. refs/heads/develop

    • in my use case I actually need the full ref

    • I'm trying to create it like this: format('refs/heads/{0}, SYSTEM_PULLREQUEST_TARGETBRANCH) but then I get this error Unrecognized value: 'SYSTEM_PULLREQUEST_TARGETBRANCH'

Is this fully supported for GitHub repositories and if not, when will it be? Any recommendations of how I can make this work?

Hello, Azure DevOps user here,

Since the branch name is MERGE i did my own solution for this, i know that the Sonarqube tasks can fix that and "automagically" solve this problem , but i'm trying to avoid installation of some extensions in the process of creating new organization (for my use case), so i'm using the sonnar-scanner in this way:

```
steps:

  • script: |
    if [ -n "$SYSTEM_PULLREQUEST_SOURCEBRANCH" ]; then
    REMOVE="refs/heads/"
    BRANCH_NAME="${SYSTEM_PULLREQUEST_SOURCEBRANCH//$REMOVE/}"
    SYSTEM_PR_SOURCE_BRANCH="${SYSTEM_PULLREQUEST_SOURCEBRANCH//$REMOVE/}"
    SYSTEM_PR_TARGET_BRANCH="${SYSTEM_PULLREQUEST_TARGETBRANCH//$REMOVE/}"
    else
    BRANCH_NAME="$BUILD_SOURCEBRANCHNAME"
    fi
  chmod +x sonar/sonar-scanner/bin/sonar-scanner
  ./sonar/sonar-scanner/bin/sonar-scanner -Dsonar.projectKey=$(Build.Repository.Name) \
    -Dsonar.log.level=DEBUG \
    -Dsonar.verbose=true \
    -Dsonar.password=${{ parameters.SONAR_TOKEN }} \
    -Dsonar.host.url=${{ parameters.SONAR_URL }} \
    -Dsonar.sources=src \
    -Dsonar.branch.name=$BRANCH_NAME \
    -Dsonar.exclusions=${{ parameters.EXCLUSIONS }} \
    -Dsonar.inclusions=src/** \
    -Dsonar.javascript.lcov.reportPaths=${{ parameters.SONAR_LCOV_PATH }} \
    -Dsonar.pullrequest.key=$SYSTEM_PULLREQUEST_PULLREQUESTID \
    -Dsonar.pullrequest.branch=$SYSTEM_PR_SOURCE_BRANCH \
    -Dsonar.pullrequest.base=$SYSTEM_PR_TARGET_BRANCH \
    -Dsonar.analysis.repositoryName=$(Build.Repository.Name) \
    -Dsonar.analysis.buildId=$(Build.BuildId) \
    -Dsonar.analysis.repositoryId=$(Build.Repository.ID) \
    -Dsonar.analysis.projectName=$(System.TeamProject) \
    -Dsonar.analysis.projectId=$(System.TeamProjectId) 
displayName: "run sonar-scanner"
i lost the pull requestion identification at the sonarqube portal, i've checked the passed parameters,

...

  • sonar.pullrequest.base=master
  • sonar.pullrequest.branch=abc999
  • sonar.pullrequest.key=1427
    ...
    ```

i don't know why but only works when i use the SonarQube Extension, the parameters are useless in this case =(

at least this workaround show the branch correctly at the portal:

image

Hi @defaultbr,

Please go to our support forum, should you have any problems that you need help for : https://community.sonarsource.com

And please note also that if you are using the Community Edition of SonarQube, branches and pull request analysis are not supported. Thanks !

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ThomasBarnekow picture ThomasBarnekow  ·  3Comments

timfish picture timfish  ·  3Comments

yaananth picture yaananth  ·  3Comments

syltaxue picture syltaxue  ·  3Comments

alexszilagyi picture alexszilagyi  ·  3Comments