When reading the documentation, it says that when doing a pull request, the "source" azure pipelines file is read when doing the PR check.
How is this in any way secure? Any developer that executes a pull request can now use the service connections the build might use and do whatever they want with it.
In other systems, it always uses the target branch CI configuration for pull requests. Is there any way to configure Azure Devops for this behavior?
What's the best practice here?
Related
I have been reading the Azure Devops docs and I am completely confused by them. All I want to is something very simple (simple with Github Actions in Github anyway) where
A developer creates a PR.
As the PR is created Azure runs all the associated Cypress tests
If any fail then the notes at the top of the PR indicate this. For example just next to the bit where it says 'there are merge conflicts'
We had this working in Github, but I can't figure it out here.
Thanks
There is no extension like "Cypress GitHub app" in azure devops, so it is impossible to achieve exactly the same function as in github pull request.
As a workaround , you can try to add status policy.
Using status alone, details from an external service can be provided
to users within the PR experience. Sometimes, sharing information
about a PR is all that is necessary, but in other cases PRs should be
blocked from merging until requirements are met. Like the in-box
policies, the Status policy provides a way for external services to
block PR completion until requirements are met. If the policy is
required, it must pass in order to complete the pull request. If the
policy is optional, it is informational only, and a status of
succeeded is not required in order to complete the pull request.
External services can use the PR Status API to post detailed status to your PRs. The branch policy for external services brings the ability for those 3rd party services to participate in the PR workflow and establish policy requirements. This article guides you through the process of configuring a branch policy for a service that is posting PR status.
In addition, here is a ticket about how to create required pull request status check, you can refer to it.
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.
Right now i see that only pull request URL is supplied through the notification. Is it possible to modify either the azure devops connector or modify azure repos subscription in microsoft teams to include approval as well
First off, with the default connector, I didn't see that possibility. We have a similar use case and we use a LogicApp or Power Automate to do what you want with REST API calls.
Link to the documentation: https://learn.microsoft.com/en-us/rest/api/azure/devops/git/pull%20requests/get%20pull%20request?view=azure-devops-rest-5.1
However, why have pull request approval policies if someone won't even look into the changes and approve them?
As others have mentioned, 'rubber stamping' Pull Requests goes against their intent. However, if you are looking for a command approach to Pull Requests, one does exist in the form of the Azure CLI.
The following command would approve a Pull Request:
az repos pr set-vote --id {id} --vote approve
Take a look at the docs to learn more:
https://learn.microsoft.com/en-us/cli/azure/ext/azure-devops/repos/pr?view=azure-cli-latest#ext-azure-devops-az-repos-pr-set-vote
Installation for Azure CLI can be found here:
https://learn.microsoft.com/en-us/cli/azure/install-azure-cli-windows?view=azure-cli-latest&tabs=azure-cli
Is it possible to approve pull requests from azure repos in micorsoft teams?
Agree with Daniel. It is unreasonable to approve PR directly in teams without reviewing the PR content.
But it is a good choice to display the alert of PR in teams, so that we can directly click alert to direct to PR.
To display the PR in the teams, you could check below document how to get the Pull Request Alerts in Microsoft Teams:
VSTS Pull Request Alerts in Microsoft Teams
Hope this helps.
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
Environment:
BitBucket
Concourse 3.14.0
Wondering is it possible to configure Concourse pipeline with Git webhook which will check if new commit has happened and it would trigger a pipeline build based on that trigger? I looked at https://concourse-ci.org/resources.html#resource-webhook-token, but it does not tell me how to get a webhook token from Concourse and if it does support what I am asking.
Any feedback is very much appreciated.
Concourse resources usually pull any new versions every minute or so. Whenever this frequency doesn't suit your needs, you can modify it with the check_every resource property. But values lower that 1m (one minute) are typically considered aggressive. Github implements quotas for API calls and when you have many pipelines, you don't want them to fail because you've hit some quota limits.
In case you want Concourse to immediately react on published new versions for the pipeline resources, you need to reverse the pattern. Instead of Concourse pulling any new versions at some defined frequency, you start pushing the information to Concourse that some new versions are to be pulled. This reversed “push” pattern involves triggering “resource checks” whenever new versions are created on the resource.
Trigger immediate resource checks
Every Concourse resource can enable a resource-check triggering URL with the webhook_token resource property. This URL includes the webhook_token secret in its query string, and is supposed to receive a mere POST HTTP request.
With Github repositories, you can POST to this URL with a Github workflow, relying on a standard Github action from the marketplace (recommended, first choice), or a Github webhook (second choice).
Using a Github workflow
You need to commit and push a YAML file in the .github/workflows folder of your Github repository, in order to define your workflow. Refer to the documentation of the “Trigger Concourse resource-check” action for detailed examples. It's very easy, as only five simple inputs need to be configured.
Using a Github webhook
With this alternative, you can manually setup a Github webhook in your repository. The URL depends on the resource for which an immediate check is to be triggered, so you can't set it up at your Github organization level. The webhook_token secret in appended in clear-text to the URL set up for the webhook, and can't be stored as a Github secret. Github webhook don't support fetching any Github secret.
And in case you're bored of manually set up webhooks, automated setup is possible with the github-webhook resource. You can even trigger the webhook recreation whenever the webhook_token secret changes in Credhub, with the help of the Credhub resource. I've done some working code implementing this idea, see those example jobs and those example resource definitions.
But I definitely recommend using a Github workflow with the “Trigger Concourse resource-check” action as a first choice.
I think you are looking for this resource - https://github.com/concourse/git-resource
It automatically checks for any new commit in your git repository and you can run other jobs based on that.
Example pipeline.yml:
resources:
- name: git-repo
type: git
source:
uri: git#github.com:concourse/git-resource.git
branch: master
private_key: {{GIT_KEY}}
jobs:
- name: run-on-new-commit
- get: git-repo
trigger: true
- task: do-something-else