When a pull request is created using the Azure Devops website, it automatically associates related work items for the commits to be merged. However, when a pull request is created using the Azure CLI (az repos pr create) the work items are not associated.
Is there a way to automatically associate the works items via the Azure CLI? They can be manually associated with az repos pr work-item add, but I'm hoping there is a way to have it happen automatically like the site does.
Not now. There is a bug for this behaviour: [Bug] Different Behavior on "az repos pr create" and web interface.
Related
We use Azure DevOps for our CI/CD pipelines, but our repositories are in GitHub. We currently trigger the CI pipelines on each push, but there is no link to GitHub so we lose easily seeing the status of a build in pull requests / automatically failing a check if a build fails.
Azure Pipelines has an app on GitHub Marketplace for integrating pipelines with repositories / pull requests. I installed this in our GitHub organization and configured it with the repository access it needs, which then had me authenticate with Azure DevOps, select the project and the pipeline yaml associated with the repository.
This works great and I can see the status directly in a pull request -
The issue is that I have multiple pipelines I would like to run and display the status of in the pull request. We have a monorepo but I only want to build an app if it was modified, so I utilize path filters in the Azure Pipelines yaml so the CI is only run when I need it to. GitHub does not discover/display the status of other CI pipelines I have in the project.
Initially, I tried just setting up another azure pipelines yaml that is triggered by pull requests. When I make a pull request, I see in Azure Pipelines the CI was triggered by 'PR automated for {pr number}', but it does not display it's status in GitHub.
I ended up going to the Azure Pipelines app settings in GitHub, 'revoking' access to the repository, and then immediately re-configuring it with access to the same project as before, but selecting a different pipeline yaml. This worked, it retained the first build I configured and added the second, and now multiple builds are shown in the pull request -
But this does not seem like the intended way to accomplish this. The GitHub app links to the entire documentation for Azure Pipelines, not specifically to docs about the app, and I have not been able to find any info within on how to do this.
Is there a way to add multiple pipelines with the Azure Pipelines app on GitHub, outside of this workaround?
We have Git repos in GitHub and work items in Azure DevOps (Azure Boards). We are using the "Azure Boards" GitHub app, and thus when we add AB# to a PR comment, it links to the right work item in Azure DevOps?
We would like to create a list of recent GitHub pull requests that show the Azure Boards work item that is associated and its parent work item. We could do this when our PRs were in Azure DevOps Git, but it seems tough to do so with PRs ion GitHub.
Would something like this be possible with existing GitHub apps? If not, how would I get start writing a bot to perhaps populate the needed info into the PR title?
Is there a way to create a rule in Azure DevOps which enforces linking work items to azure repo commit as mandatory?
You cannot enforce linking work items for individual commits. However, you can require that work items be linked as part of your Pull Request Policy.
Here's Microsoft's documentation on how to set it up:
https://learn.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops#check-for-linked-work-items
I created a classic CI azure pipeline for a .net application present in GitHub repo and enabled continuous integration in triggers and also added 2 branches in branch filters. But when my team members made some changes and make commits, my pipeline is not triggering and build is not created. I can't understand what might be the problem as I'm new to azure pipelines
Here is some troubleshooting advices, and you can click this document for more detailed information:
Are you using the GitHub app connection to connect the pipeline to GitHub? If you are using a GitHub app connection, follow these steps:
Is the mapping set up properly between GitHub and Azure DevOps? Open a
pull request in your GitHub repository, and make the comment /azp
where. This reports back the Azure DevOps organization that the
repository is mapped to.
If no organizations are set up to build this repository using the app,
go to
https://github.com/<org_name>/<repo_name>/settings/installations and
complete the configuration of the app.
If a different Azure DevOps organization is reported, then someone has
already established a pipeline for this repo in a different
organization. We currently have the limitation that we can only map a
GitHub repo to a single DevOps org. Only the pipelines in the first
Azure DevOps org can be automatically triggered. To change the
mapping, uninstall the app from the GitHub organization, and
re-install it. As you re-install it, make sure to select the correct
organization when you are redirected to Azure DevOps.
Are you using OAuth or PAT to connect the pipeline to GitHub? If you are using a GitHub connection, follow these steps:
OAuth and PAT connections rely on webhooks to communicate updates to
Azure Pipelines. In GitHub, navigate to the settings for your
repository, then to Webhooks. Verify that the webhooks exist. Usually
you should see three webhooks - push, pull_request, and issue_comment.
If you don't, then you must re-create the service connection and
update the pipeline to use the new service connection.
Select each of the webhooks in GitHub and verify that the payload that
corresponds to the user's commit exists and was sent successfully to
Azure DevOps. You may see an error here if the event could not be
communicated to Azure DevOps.
Is your pipeline paused or disabled? Open the editor for the pipeline, and then select Settings to check. If your pipeline is
paused or disabled, then triggers do not work.
Have you used variables in defining the trigger or the paths? That is not supported.
Have you excluded the branches or paths to which you pushed your changes? Test by pushing a change to an included path in an included
branch. Note that paths in triggers are case-sensitive. Make sure that
you use the same case as those of real folders when specifying the
paths in triggers.
Updates:
You don't need to change webhooks in github, what you need to do is that go to github Settings -> Webhooks, check whether there are "Recent Deliveries". If there are errors in recent deliveries, the cause of the question is indicated.
If Azure DevOps and GitHub are properly connected, GitHub will automatically generate Webhooks. As shown below:
The content of "Payload URL" is:
https://dev.azure.com/{organization}/_apis/public/hooks/externalEvents?publisherId=github&channelId={channelId}&api-version=6.1-preview
Please note that a GitHub repository can only connect to one Azure DevOps organization. If you have connected to more than one organizations, keep the only one you are using currently.
In DevOps click Pipelines on the left-hand side navigation
Select your pipeline.
Click Edit
Then in the new window pane (top left), you'll see a tab for triggers.
This is where you can configure the continuous integration settings to trigger builds on push / pull requests etc.
Here's an example
Continues integration is enabled for the development branch, thus any push to that branch will trigger a build.
I was trying to have a full change from the commit to the pull-request/review process in a Azure DevOps repo with Visual Studio Code.
All good till the point where I have to create a Pull Request.
I didn't find an embedded way to do it.
There is a plugin Pull Requests for Azure Devops but it seems to be not maintained anymore.
Do you know any other good way to do it? Or may be Microsoft can invest in this important feature?
In our team, we started using the Azure CLI but found it too verbose to be practical. We also wanted to have a similar API to the GitHub CLI.
To fix this, we developed doing-cli, which is essentially a wrapper around the Azure CLI with a feel of the GitHub CLI.
A typical workflow for us is:
doing list to see open work items
doing issue create <issue title> to create a new work item
doing pr create <issue number> to create a branch and a PR based on an existing work item
Our company requires that all PRs are linked to a work item. But sometimes you want to fix things quickly, without having to always create a new work item, create a new branch, link them and open a PR. So we implemented doing workon <title> which will do all these steps for you, as well as checkout the newly created branch.
There used to be an extension, but it got pulled.
When you install the azure cli and the devops extension and then create a pull request from the terminal:
az extension add --name azure-devops
az devops configure --defaults organization=https://dev.azure.com/contoso project=ContosoWebApp
az devops pr create --repository MyRepo --open --source-branch branch-name
That last command needs 2 parameters that can be teased out of the context in a repo folder, that way you can easily alias this to a generic command.
Very few people were uring the Azure Repos and PR for Azure DevOps extensions. And most of Microsoft's investments are in GitHub.
As suggested by Jessehouwing's answer, you can create pull requests using Azure CLI.
In addition, you can also use the REST API Pull Requests - Create:
POST https://dev.azure.com/{organization}/{project}/_apis/git/repositories/{repositoryId}/pullrequests?api-version=6.0
Here is an example of the request body:
{
"sourceRefName": "refs/heads/npaulk/my_work",
"targetRefName": "refs/heads/new_feature",
"title": "A new feature",
"description": "Adding a new feature"
}