I checked several sources, seems possible, but can't get it work.
What I want is that whenever a PR is created and PR build is successful, then a PR release is run and a site is created (either with PR Id or PR source branch, e.g. pr122--xxx.azuresite.net).
From an answer for this question,
Looks like I could use release.artifacts.alias.PULLREQUEST.ID, but when I tried it, this doesn't work at all. Also from the official doc, there is no mention of this variable. Is this only for the new YAML pipeline?
As most of our things are in classic pipeline, the solution I can think of is to parse the build source, which is refs/pull/11201/merge. Looks like 11201 is the Pull Request ID, so I just need to replace refs, pull,merge and "/". But I am not sure if better approaches available.
Following this doc: Deploy pull request Artifacts with Azure Pipelines, we can successfully create a pull request deployment by choosing Azure Repos as the source artifact.
If one pull request is created, a new release will be triggered. And as you have found, the source branch of build source is "refs/pull/{PullRequestId}/merge", so you are right.
In addition, if you set the Azure Repos as the primary artifact, we can get the pull request branch by using the predefined variable Release.Artifacts.{alias}.SourceBranch. In below example, we can use the PowerShell task to run below command.
Write-Host "Release.Artifacts._215.SourceBranch: $(Release.Artifacts._215.SourceBranch)
See: Default variables - General Artifact for details.
Related
I'm trying to create a release pipeline with PR trigger. I saw in every documentation, that there should be a "Pull Request trigger" toggle in the artifact like here:
However when I click the Continuous deployment trigger icon, there is no Pull request trigger:
I don't know what I'm doing wrong, I followed every step from Microsoft's documentation.
On stage triggers it shows the PR trigger option with a warning:
I created multiple new pipelines, the toggle just doesn't show up. The artifact is built from code on Github
This situation may be if you are using Team Foundation Version Control for your builds:
TFVC does not support pull requests. Please, verify you are trying to use GIT in your build pipeline:
To ensure the uniqueness of every artifact download, each artifact source linked to a release pipeline is automatically provided with a specific download location known as the source alias. Please see the official doc for more details: Artifact source alias
I notice:
1.The original build name own ''.
2.Your source alias without the download location ''.
if I change the source alias by cutting the '_', chances are not seeing the pull request trigger part. It's not related to repo location, repo type when you choose build type artifact.
The workaround is:
If your artifact source alias name doesn't have ''or'-', then you could cut the system added ''.
If you do want cut the system added '', please don't add '' in artifact source alias name.
For your reference, if you want to change artifact source alias name, you can change the name of the build pipeline.
I hope this could do some help.
I'm using azure for a windows app and so I don't really need to go as far as CD as that isn't really relevant. We eventually plan to move to the cloud but for now that is not the case.
I have now got my .net (c#) build running as a build pipeline and I have a develop branch which Pull Requests are used to merge in changes. What I want is for a tester to be able to pick up the build artefact that was created for a particular bug or product backlog item when the pull request was successfully completed. Is this possible without having a Release Pipeline? I don't currently have a subscription that would allow me to create a release pipeline.
How can I access the artefact from a pull request for which a build was run?
Indeed, just as Lucas said, if we are starting from the pull request to solve this problem, it is really difficult. But we could try reverse thinking to start with the build pipeline.
Azure devops provided us some predefined variables, like Build.BuildId, System.PullRequest.PullRequestId.
So, we could use the REST API Pull Requests - Update in the build pipeline to update the comment with the link to the artifact.
PATCH https://dev.azure.com/{organization}/{project}/_apis/git/repositories/{repositoryId}/pullrequests/{pullRequestId}?api-version=5.1
Since the current build is triggered by a pull request, we could use the predefined variable System.PullRequest.PullRequestId to get the pullRequestId directly.
Now, we just need to get the link of the artifact, we could use the Artifacts - Get to get the artifact info:
GET https://dev.azure.com/{organization}/{project}/_apis/build/builds/{buildId}/artifacts?artifactName={artifactName}&api-version=4.1
We could get the buildId by the predefined variable Build.BuildId, then we will get the download URL:
So the idea of summing up my solution is to use REST API Pull Requests - Update in the build pipeline to update the comment of the pull request, which contains the download path of the artifact.
Note: You could also add custom conditions in the REST API task in the build pipeline:
and(succeeded(), eq(variables['Build.Reason'], 'PullRequest'))
So, with this setting, only the build triggered by the pull request will execute this rest api task.
Hope this helps.
The pull request build that you defined can publish artifacts, see this documentation to see how to do it.
Once those artifacts are published, your tested can browse/download them on the build run page (click on header pa> "Related" > click on "#number of artifacts you publish# published").
Alternatively, you could add a task to copy your artifacts to an Azure Blob Storage, but that would require more configuration.
One can find build id with branchName filter :
GET https://dev.azure.com/{organization}/{project}/_apis/build/builds?api-version=5.0&reasonFilter=pullRequest&definitions={buildDefinitionId}&branchName=refs/pull/{pullRequestId}/merge
Once builder id has been retrieved, get artifact by name :
GET https://dev.azure.com/{organization}/{project}/_apis/build/builds/{buildId}/artifacts?artifactName={artifactName}&api-version=6.0
I have repository on local GitLab server of my organization and want to trigger build pipeline that then will trigger release pipeline and publish to staging/production VMs.
I've read a lot of articles at microsoft docs, SO and tons of blogs that you can trigger pipeline by tags providing branch filter like refs/tags/v*. YAML configuration has additional section special for tags, however YAML is not supported for git repos that are connected as "Other git".
And that tag trigger just never works. After I set up trigger UI shows me just "v*", so it understands that refs/tags has special meaning. I can run pipeline manually specifying exact tag, like refs/tags/v1.0-test, and it works. But never launches automatically. Branch triggers work without problems.
What I've already tried:
set include filter for refs/tags/v* - doesn't work
set include filter for refs/tags/exacttagname - doesn't work
set include filter for refs/tags/v* and another one for master - triggers only for master
set include filter for refs/tags/v*, for * and exclude filters for refs/heads/* and refs/remotes/* - doesn't work
I tried pushing commit, then pushing tag. Tried pushing commit and tag in one requiest with git push ---follow-tags. Tried pushing tags for older commits. Nothing of that works.
This issue about the same problem was resolved on azure side previous summer, however all comments where about GitHub integrations. So maybe it's still broken for "other git" or smth else.
Any help?
I tested and got the same result, tags triggers for other git doesnot work. You can submit a feature request(click suggest a feature and choose Azure devops) for supporting tag triggers for gitlab repo to Micrsoft Development team. Please check this thread for example.
As workaround you can use multiple agent jobs to achieve above currently.
You can add another agent job before your original agent job to run a script task, And add dependency on it in your original agent job. The script task will check if there is tag associated to the current commit. If the tag exits, the script task will pass, and the following agent job will run. Or the script task fails and the following agent job will be skipped.
The detailed steps is as below:
add a agent job with a single powershell task. Check below screenshot.
Run below inline scripts in the powershell task to check the tags
$tags = git describe --tags $(Build.SourceVersion)
if($($tags) -notmatch 'v.'){exit 1} #fail the task if the tag doesnot match v*
In the original agent job, add dependencies to above agent job.
Go to Triggers tab and filter all branches.
I have a repo which has two branches:
develop (repo's default branch)
master
Code within the develop branch is known to be releasable as an "alpha" version, while code within master is known to be production ready.
Currently, the develop branch's policies requires that a CI build must successfully complete for the PR to merge. That build will create NuGet package artifacts with a prerelease tag (alpha-####).
A release pipeline is responsible for taking these packages and publishing them to an internal NuGet feed.
What I'm trying to achieve is to have the release pipeline triggered automatically when the PR is completed, not whenever the CI build succeeds.
I expected the "pull request trigger" to do just that, but much to my surprise the trigger won't acknowledge the PR's status and have the release pipeline start as soon as the CI build is completed.
This means that if the PR gets rejected for whatever reason, a NuGet may still be deployed to my feed!
What am I doing wrong here? How come the pull request trigger doesn't work any differently than the continuous deployment trigger? What's it's purpose then? :/
The continuous deployment trigger means, if you specify certain types of artifacts in a release pipeline, you can enable continuous deployment. This instructs Azure Pipeline to create new releases automatically when it detects new artifacts are available.
The Pull request trigger means, once a pull request release is configured, anytime a pull request is raised for the protected branch, a release is triggered automatically, deployed to the specified environments.
So these two triggers are different and more detailed information you can refer to here.
https://learn.microsoft.com/en-us/azure/devops/pipelines/release/deploy-pull-request-builds?view=azure-devops
https://learn.microsoft.com/en-us/azure/devops/pipelines/release/triggers?view=azure-devops
And if you still want to deploy your Nuget after a PR completed, I recommend you to create a new build pipeline and enable the Continuous integration for it. Then set this build pipeline as the Release pipeline Artifact.
Because when a PR completed, it will create a new commit to the target branch and this new commit will trigger the build pipeline, and the build pipeline will trigger the release pipeline to deploy the Nuget as your expected.
Not sure if anyone's still looking for a solution to this over a year after the fact, but I was so I wrote an Azure Function app to receive pull request close webhooks from DevOps and translate those events into new releases.
You can find it here on my github: https://github.com/GravlLift/OnPullRequest
Feel free to fork it to fit whatever your individual needs are.
Is there a way I can set up a build in Azure DevOps to automatically run every time a PR is merged and completed and contains a specific keyword in the name? for example: "Some PR name here [RUN_BUILD_123]"
Edit:
The reason for this is because I have different builds on top of the same branch so instead of triggering all the builds I just want to trigger those that I know need to be rebuilt based on the particular projects getting changed.
A PR has a target-branch. If you want to trigger a build after a PR is completed just configure a build with a ci-trigger for that target-branch. You can't check for certain keywords in the PR-name unfortunately
Agree with D.J. For detailed setting, you can check the Enable continous intergration option in the Triggers settings, then select the target branch you want ci-trigger build in the Branch filters.This will automatically trigger the build after pr is completed.
But you can't do it if you want to include special keywords in pr name.
Topic is a bit old, but if there is anyone who want's to archive this stumbling over this topic - here is my approach how I would solve this:
The basic of all are scripted pipelines, so if you still do it in the GUI - that's wasted time. Create a .yml build and put it into your Git. The M$ documentation is really helpful with this.
Create the trigger for your branch
Put this on the first line, so the pipeline will be executed when master (or your branch) has a new commit
trigger:
branches:
include:
- master
Read out the commit message via the VSTS variables
Trigger the builds, based on their ID via REST API (you can use the pipeline token for authentication)