I've an issue with two existing pipelines that refuse to queue any build on PR.
Every repository in our organisation has its own build policy on master & release/ branches.
The message in the PR is "1 required check broken: Unable to queue Build".
Others existing pipelines are working correctly.
In these two repositories I can trigger a pipeline build manually but not automatically.
I've tried to deactivate the existing build policy or to delete it and recreate it but without success. When I try to delete the existing pipeline I encounter the error : «TF400898: An Internal Error Occurred. Activity Id: .».
I've successfully managed to delete an existing pipeline from an old repository, so I have the permission to delete a pipeline.
Any hint ?
Please check if you have selected the do not queue new builds option in your pipeline. It should work normally if you change it to the Enabled option.
Related
i want to prevent the User from merging a PR if a specific pipeline failed. But i don't want to trigger the pipeline again but i want to use the latest run because the pipeline is a scheduled systemtest.
The "Build Validation" policy has no option to check the latest run of a pipeline.
Add build policy
Is there a way to achieve this?
I am afraid that there is no such method can use Build Validation to check the latest run instead of triggering new pipeline.
Refer to this doc: Build validation
A build validation policy queues a new build when a new PR is created or changes are pushed to an existing PR that targets the branch.
Triggering new build is the default behavior of the Build validation in Branch Policy.
I suggest you can add an extra pipeline to set the branch policy, in the extra pipeline you can use the Rest API: Latest - Get to check the latest running status of the target pipeline
I want to have my build pipeline configured such a way that when ever my pipeline fails there is a bug created for the same. I cannot find an option to select this configuration for a particular branch. Can someone help me with this.
I want to create a bug whenever my build pipeline fails in azure devops. And i want to have it configured for a particular branch
There is an option Create a work item on failure on the pipeline Options tab.
If the build pipeline fails, it can automatically create a work item to track getting the problem fixed.
But we could not configurate it for a particular branch for this option, but we could create a new pipeline with trigger filter Branch specification:
In this case, only the particular branch build failed, it will create a bug.
I've been playing around with setting up validation for pull requests and now I can't fully remove unnecessary pipeline. I've deleted it under project/Pipelines tab. But when I create new pull request I can't merge it. Said pipeline still appears under "checks" with "deleted pipeline name not run". Said pipeline can also still be found under "Deleted pipelines".
I've tried setting pr: none in underlying .yml file, removing said .yml file, adding [skip ci] in title. I can't find anything in policies tab for the project or organization. I am an admin on project if that changes anything. Is there anything else I could do?
Edit: Using Azure Devops.
Assuming you're using GitHub, go to your repo > settings > Branches > Branch protection rules > your protected branch > edit > Status checks that are required
Remove the status check that no longer runs.
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've been using Azure DevOps for a while now, and CI has been working great. I commit to my branch, and it kicks off a branch automatically.
This has all of the sudden just stopped working.
I have tried all of the ideas from this question:
VSTS continuous integration triggers not working
But I cannot get it to trigger the build automatically.
Please help!
I faced the same issue and the fix was to delete unwanted GitHub service connections in 'Project Settings'. Multiple service connections using oauth and azure pipeline to same GitHub account was present. Once it is removed, pipelines were getting triggered automatically.
Azure DevOps CI trigger is not working even though the setting is set
Some times service event( https://status.dev.azure.com/ ) in Azure DevOps may cause this issue. Besides, if there is [skip ci] in commit message, the build will skip the CI trigger.
Check the document Skipping CI for individual commits for some more details.
Besides, if it still does not work now, try to manually Queue a build, then commit to to your branch again and check if it works for you. If not, try to create a new build pipeline to check if still have this issue.
Hope this helps.