I am trying to use the service hook of azure devops, and while applying the the filter “Run Job state changed webhook”.
The pipeline running contains 8 jobs and when their states change none of them triggers the webhook and there is no attempt in the history of the pipeline. However when trying to test the service hook using the “Test” button, the attempt succeeds and the request is received normally.
Any ideas what might be the root cause of the problem and how to fix it?
Thanks in advance
Related
I have created a custom PR status check to validate my PR follows a conventional commit like pattern. This is in Azure Devops Git, not Github. To do this, I created an Azure Function App and setup a status check in Azure Devops. Here is the configuration:
I enabled the PR status check for my branch. Here is the config for that:
The PR status check appears and actually works....when I invoke the call manually. I can use postman to invoke my function (with a PAT I generated for my account) and it will update the status on the PR. But if I commit to the branch, the step sits there on the validation step even though I have the checkbox checked to "Reset status when there are new changes".
This is what it looks like after I invoke the function manually through postman
I would expect the system (AZDO in this case) to invoke my function every time a new iteration was created (i.e. when a new commit is pushed to the branch). Can someone point out what I'm missing? Thanks!
Ended up coming up with solution. I don't have privs to add a an authenticate an application to run the pipeline because of the way our org is setup. So I created a node script to accomplish what the function app is supposed to do.
I've been trying to fix an issue with our CDK pipeline. The pipeline was failing at the UpdatePipeline stage, while trying to perform the SelfMutate action. It turned out that we had recently made a change in the pipeline code to use a secret corresponding to the personal access token from a different github account. This new account did not have access to the repo containing the pipeline code. Once the account was given access, the pipeline was able to run successfully.
However, while trying to diagnose the problem, I temporarily pushed a change to add selfMutating: false to the CDK pipeline. At first, the pipeline continued trying to run the SelfMutate action (maybe because the github access issue meant it couldn't see this change). Once I resolved the access problem, the pipeline ran successfully and removed the UpdatePipeline stage altogether.
I then reverted my change, thinking that UpdatePipeline and SelfMutate would be reinstated. However this has not happened, and the pipeline is now running with this stage being missed out altogether.
Why has this happened and what can I do to reinstate self-mutation?
If you turned off self mutation then subsequent deploys will not affect the pipeline.
To fix this you need to enable self mutation and deploy the pipeline stack manually from you machine to update.
We are using Azure Pipelines to spin up pull request environments, but we are looking for the best way to delete the environments when the PR is closed (completed/abandoned).
Currently, we use a service hook that fires when the PR status is changed, hitting a custom Azure Function API, which then determines whether to delete the environment and, if so, deletes it.
This seems like it would be a common scenario, so wondering if there are better alternatives?
This seems like it would be a common scenario, so wondering if there are better alternatives?
Agree with Shayki. What you are doing is the best way, and this is what we are currently using.
That because azure devops does not have the feature to trigger the pipeline after the PR completed. Pull request trigger and Build Validation both trigger the pipeline when the PR starts.
So, we need create a service hook to monitor PR status. If the PR status changes, the pipeline is triggered through API or Application.
I have code in GitHub and build in Azure DevOps
Build is executed nightly but Service connection Usage history is always empty for GitHub:
Any ideas how to figure out which pipelines use which service connection?
Any ideas how to figure out which pipelines use which service
connection?
Per my experience, the execution history there indicates the history of Github connection usage during pipeline run instead of pipeline checkout. So if we don't use the service connection in any of our task, the history would be empty.
Some details:
I have one pipeline which uses one private github repo as source:
Run the pipeline three times, build number #1434, #1435 and #1436. #1434 only has one simple CMD task while the next two runs (#1435,#1436) have extra github-related tasks which uses that github connection as task input.
#1434(Use the github connection in Get Source step but not in Real run process):
#1435 and #1436(Call the github connection in real run process):
The result after several minutes:
For now the Guthub Connection usage history won't display the history of the pipeline run during which the connection is only used for Get Source authorization. We have to check it ourselves if any pipeline uses the connection for Get Source step.
In addition: I think this would be a good idea if the usage history can also display the history of runs that use the github connection for Get Source Authentication step. So feel free to submit a feature request in our User Voice forum to share your idea with the product team if you do want this feature. They would consider it seriously if it gets enough votes.
Azure DevOps Pipelines - Get API can be used to fetch metadata about repo and if it's GitHub compare service connection Id with wanted, sample solution -
https://dev.azure.com/kagarlickij/_git/azuredevops-check-service-conn-usage
I tried batch: true setting described here, but it seems to:
ignore commits that are pushed when a pipeline is running. I want the last commit to trigger a pipeline after the current run of that pipeline has finished
be ignored when you publish directly from CI by pressing build
Has someone found a way to configure a pipeline to run as I have described.
You can try adding a Invoke REST API check on the agent pool. The rest api will get the previous build and evaluate its status. So when new build is queued targeting the agent pool. The Invoke REST API will be invoked, this new build will only start when the response of the rest api is evaluated to true.
Please check below steps：
1, create a service connection to your azure devops organization.
Go Project Setting--> Service connections under Pipelines-->Click new service connection--> select Generic to create a generic service connection.
Then Edit the service connection type the information shown in below screenshot. Check here to get a Personal access token.
2, add Invoke REST API check on the agent pool**.
Go Project Setting--> Agent Pools under Pipelines-->Select the agent pool--> Click the 3dots -->Click Approvals and checks.
.
3, Click the "+"--> Choose Invoke REST API
4, Edit the Invokde Rest API
Select the generic service connection to your azure devops created in the first step.
Set the fields as below:
URL suffix and parameters: _apis/build/builds?definitions=the DefinitionId of your pipeline&$top=2&queryOrder=queueTimeDescending&api-version=5.1
Success criteria: eq(root['value'][1]['status'], 'completed')
please check here for more information about build rest api.
Note: Since the Invoke Rest api check is set on agent pool scope. It may have effects on other pipelines that target this agent pool. For example, if the desired yaml pipeline is waiting its previous run to complete. And now another pipeline targeting this same agent pool is triggered, it will have to wait for the previous run of desired yaml pipeline to complete too.