I have installed Azure Pipelines Marketplace app on GitHub: https://github.com/marketplace/azure-pipelines
During the installation process, I selected the repository and ended up with the configuration flow to create a new .yml file.
BUT - I already have a rather advanced build definition set up in Azure DevOps (configured 2-3 years ago) and it won't let me export it to YAML.
So as a result, when a Pull Request is opended the Checks tab in GitHub shows the Azure Pipeline check, but just says it is queued and it never updates:
Status checks are still reported back to the PR, using the old way - the top one is build status, reported back automatically from Azure DevOps PR trigger:
You should remove completely Azure Pipelines application:
go to your GitHub installation settings : https://github.com/settings/installations or https://github.com/[organization]/[project]/settings/installations
open configuration for Azure Pipelines
Uninstall Azure Pipelines application
Then reinstall https://github.com/marketplace/azure-pipelines application.
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?
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 am following the steps outlined here. I am using the Deploy to Azure Extension
https://learn.microsoft.com/en-us/azure/devops/pipelines/targets/deploy-to-azure-vscode?view=azure-devops#github--azure-pipelines
I have done the following steps.
I have managed to create a simple react app and then got the GitHub + GitHub Actions portion to work no problem.
Now, I want to get GitHub Plus Azure Pipeline to work. So, I deleted the GitHub Actions/Workflow files, and starting over with the CICD setup.
Next, I have enabled Use Azure Pipelines for GitHub in the extension.
Then, as per the steps/pictures outlined in the above microsoft documentation link, I have begun the configure CICD option from the command palette.
Selected the Visual Studio Subscription
Selected the target web app
Now, at this point, as per the linked tutorial, it is supposed to ask me to choose a azure devops organization, so that the azure pipeline YAML file can kick in. This step never happens.
instead, VS Code will proceed to generate a GitHub Actions Workflow just as it did before.
What should I do to the GitHub to Azure Pipeline working from this extension?
Update 1
In case anyone is curious, I have raised a issue on the visual studio community forum. You can find that here
https://developercommunity.visualstudio.com/content/problem/1182952/github-azure-pipelines-falls-back-to-github-github.html
As of now, there is an ongoing discussion but no solution yet.
You can try reinstalling Deploy to Azure Extension and enable Use Azure Pipelines for GitHub, and then configure CI/CD option again. If the issue persists, you can report this issue here.
You can create a pipeline directly in your azure devops project. Check out below tutorial
Build, test, and deploy JavaScript and Node.js apps
You will also need to create an Azure Resource Manager service connection to deploy to your azure resource from azure devops pipeline.
Deploy an Azure Web App (Linux)
I setup an Azure CI/CD to build my project from a Bitbucket location with a YAML pipeline
However whenever I push to my branch that is included in the trigger branches, Azure Pipelines keeps saying that it's been triggered by:
If I wanted to make change using the web UI editor and push, it will show to run under my username.
How can make all triggers to look under usernames?
I am trying to add Azure Pipelines configuration to an existing project, bundler/bundler. Here is the PR that adds the configuration:
https://github.com/bundler/bundler/pull/6899
As one of the maintainers set up the bundler/bundler project on Azure Pipelines, this PR already triggers a build:
https://dev.azure.com/bundler/bundler/_build/results?buildId=11
Note that the build has a green checkmark and is marked as finished.
(Also note that there are loads of tests failing in the build, as this wasn't tested on Windows before. To make the build succeed anyway - and not all PRs and commits get the red "x" on Github while I am working on fixing the tests, I added || exit 0 at the end of the test command - which works fine on Azure Pipelines)
A feature of Azure Pipelines' GitHub integration is that the build results are shown in Github via a feature called "Check":
https://github.com/bundler/bundler/pull/6899/checks
(A shorter version of that is also included at the end of the PR page: https://github.com/bundler/bundler/pull/6899#partial-pull-merging)
Unfortunately, this check doesn't reflect the build status on Azure Pipelines and is still shown as "in progress":
and
Any idea why the GitHub check doesn't reflect the build status on Azure Pipelines?
What is confusing me further, is that the integration with Azure Pipelines actually worked just fine (check correctly reflects the build status) in the Pull Request that was automatically created by Azure Pipelines when creating the bundler/bundler project: https://github.com/bundler/bundler/pull/6955
But: It also can't really be the Azure Pipelines configuration I created in my PR, because the same configuration also works just fine in my fork: https://github.com/janpio/bundler/pull/6#partial-timeline (see the green checkmark for the bundler task). (On the other hand: Here Azure Pipelines doesn't use the "Check" feature of Github at all)
Great question. The most likely reason is that there some was glitch in the communication between Azure Pipelines and GitHub. It's very rare but sometimes a webhook between GitHub and Azure Pipelines doesn't trigger. There's no way to tell why it happened; it could have been a fault on either side.
Unfortunately, there's no way to re-send a webhook that didn't get delivered. Your only recourse is to rebuild that pull request. If you select the "Rebuild" option (in the ... menu):
Then a new build will be queued and, when it finishes, the status update will be sent back to GitHub. The check in the pull request will then be updated.
A less likely (but definitely possible) reason is that there's a bug in either Azure Pipelines or GitHub. And in this particular case, there was a bug with the code that uploads test results from Azure Pipelines to the test case manager API.
(Thanks for reporting the issue, we're sorry that we had a bit of a problem here, but we're glad that we were able to resolve this.)
Setting the following configuration worked for me: