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
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:
@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:
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.
@bprodduturi see this thread: https://github.com/microsoft/azure-pipelines-tasks/issues/8793#issuecomment-506655057
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?
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 definedSystem.PullRequest.TargetBranch
is not definedSYSTEM_PULLREQUEST_TARGETBRANCH
returns the branch name develop
rather than the ref, e.g. refs/heads/develop
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:
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,
...
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:
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 !
Most helpful comment
Hello there @chrispat and others.
Any chances
System.PullRequest.SourceBranchName
andSystem.PullRequest.TargetBranchName
variable will be added in foreseeable future? We now have onlySystem.PullRequest.SourceBranch
andSystem.PullRequest.TargetBranch
. That is not a breaking change and the implementation could be just copied from howBuild.SourceBranch
andBuild.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
andSystem.PullRequest.TargetBranchName
to match withBuild.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 |