Getting the branch policy from Azure DevOps Services return only the policy type but not the "Required reviewers" - looking for Reviewer Name or Team Name .
I could not find a call to extract the "Required reviewers" from the selected policy/branch.
looked for policy extraction method could not find .
For REST API checkout the Policy Configurations. The Confguration object in the example on the page shows a settings.requiredReviewerIds property with what seems to be an array of Azure AD Object IDs for the required reviewers.
As an alternative to REST, az cli also has the az repos policy required reviewer command documented here to manage reviewers in branch policies.
Related
I'm trying to create a release pipeline in DevOps, that releases packages to LCS. The normal Dynamics 365 FO way of working. The issue is, I don't have an admin account without MFA that can be used to do this. Which roles or general setup, should I set on the AAD user, to be able to create the release? Currently I'm getting the AADSTS7000218 error.
I created a user that doesn't have MFA and I expect to add certain roles to be able to use this user for creating releases in DevOps.
In Azure DevOps, to create release pipeline you need "Edit release pipeline" permission set to Allow. And you need to be at least a Basic user.
And as per the document, AADSTS7000218 means The request body must contain the following parameter: 'client_assertion' or 'client_secret'. When authenticating to Azure AD to get an access token, the client application is not providing its “password” (in the form of either a client secret or a client assertion) as expected by Azure AD’s token endpoint.
You could try navigating to Azure Active Directory->App Registration and find Authentication in your application. And set "Allow public client flows" to "Yes" in Azure portal.
Here's another ticket has the similar issue, hope it can help.
In Azure DevOps is their a way to gather a list of repositories that enforce "Required Reviewers on pull requests and for what branches?
You can use Configurations - List rest to get the repositories and branches that enforces "Required Reviewers" on pull requests.
GET https://dev.azure.com/{organization}/{project}/_apis/policy/configurations?policyType={policyType}&api-version=6.1-preview.1
The ID of above "policyType" for Required Reviewers is "fd2167ab-b0be-447a-8ec8-39368250530e" (You can list all the policyTypes by using Types - List rest api) See below screenshot:
So you can change above rest api to below:
https://dev.azure.com/{organization}/{project}/_apis/policy/configurations?policyType=fd2167ab-b0be-447a-8ec8-39368250530e&api-version=6.1-preview.1
See below result example:
I have a pipeline with the following:
resources:
repositories:
- repository: repo
type: git
name: TEST-staging
steps:
- checkout: repo
When the pipeline runs I get this warning:
This pipeline needs permission to access a resource before this run can continue
Which prompts me to grant access:
Granting permission here will permit the use of Repository 'TEST-staging' for all waiting and future runs of this pipeline.
I would like to be able to audit and modify which pipelines have access to which repos. Where are those permissions listed?
EDIT: User is prompted to permit access when the pipeline names the repo e.g. - checkout: repo however, user is NOT prompted to permit access when using -checkout: self even though it's the same repo.
EDIT: The organization settings for Limit job authorization scope to current project for non-release pipelines and Limit job authorization scope to referenced Azure DevOps repositories are currently and have always been disabled.
EDIT: This FAQ question is similar to my question: Why am I am prompted to authorize resources the first time I try to check out a different repository?. That FAQ leads to this documentation: Troubleshooting authorization for a YAML pipeline. That documentation contains:
When you create a pipeline for the first time, all the resources that
are referenced in the YAML file are automatically authorized for use
by the pipeline, provided that you are a member of the User role
for that resource. So, resources that are referenced in the YAML file
at pipeline creation time are automatically authorized. When you
make changes to the YAML file and add additional resources ... then
the build fails with a resource authorization error ... In this case,
you will see an option to authorize the resources on the failed build.
If you are a member of the User role for the resource, you can select
this option. Once the resources are authorized, you can start a new
build.
EDIT: This seems to be the work item for the change that is causing us to be prompted to permit access.
So, I am being lead to these conclusions:
#Leo had the correct answer to the question "Where are those permissions listed?" except when a YAML resource is added to an existing pipeline
When YAML resources are modified or edited, the user is prompted to authorize that access even when that access is already authorized via the user's role
I have re-titled this post in the hopes that it more clearly asks the question, because as of now there does not seem to be any place in which ad-hoc authorizations are listed
I would like to be able to audit and modify which pipelines have access to which repos. Where are those permissions listed?
According to the document Pipeline permissions and security roles, we could to know:
For permissions, you grant or restrict permissions by setting the
permission state to Allow or Deny, either for a security group or an
individual user. For a role, you add a user or group to the role.
Therefore, the permission of the pipeline is associated with the user executing the pipeline.
To be able to audit and modify which pipelines have access to which repos, we could use a higher authority account to give the current user permission to access the TEST-staging repo:
Organization Settings->Users->select the current user->Three dots->Manager User:
If the current user has permission to directly access the repo, then when this user executes the pipeline, the pipeline will have the permission to access the resource repo.
I am using the Azure DevOps REST APIs to do some branch policy audit work. I want to see all the policy configurations, active and deleted. The API: https://dev.azure.com/organization/project/_apis/policy/configurations/?api-version=5.0 only returns active policy configurations. In-active ones should have the isDeleted flag as true. I can access those policy configurations if I already know the configuration ID and if it is included in the API call like this: https://dev.azure.com/organization/project/_apis/policy/configurations/7001?api-version=5.0
I was wondering if there is a way to list deleted policy configurations associated with a repository or project.
Rest API does not currently support querying deleted policy configuration.
When get a list of policy configuration, REST API below only output the policy not deleted:
GET https://dev.azure.com/{organization}/{project}/_apis/policy/configurations?api-version=5.0
You could submit a suggestion ticket to suggest the new feature through this url to promote development of richer features.
Note: After suggest raised, you can vote and add your comments for this feedback. When there are enough communities vote and add comments for this feedback, the product team member will take this feedback seriously
We are trying to change the access level of users at the organization level say for example from stakeholder to basic in Azure DevOps Services programmatically - via REST API/Powershell/ARM. Could you please direct me to some documentation or any sources which can help us through.
You can do this via the Azure DevOps REST API via the User Entitlement Endpoint.
https://learn.microsoft.com/en-us/rest/api/azure/devops/memberentitlementmanagement/user%20entitlements/update%20user%20entitlement?view=azure-devops-rest-5.0