Merge pull request #5403 from MicrosoftDocs/users/chcomley/build-sugg…

…estions-01-13-2023

Build suggestions

docs/repos/git/review-pull-requests.md

@@ -94,7 +94,7 @@ You can manage PRs in Azure DevOps Services by using the [Azure DevOps command l
 
 Pull requests let designated reviewers examine, discuss, and vote on proposed changes before those changes are applied to a target branch of a repo. Keep in mind that if development is carried out with the same files on different branches there may be a conflicting changes. In that case it is required to carefully analyze and resolve those conflicts. To do so, may require manually editing the file to correctly apply the changes from either source, target or both branches. Taking all changes from either source or target (which can be done by a single button click) may not be optimal and can result in loss of some required changes. This can be done using ADO tools, or it will be more convenient to use development tools (such as Visual Studio).
 
-To learn more see [Resolve merge conflicts](/azure/devops/repos/git/merging?view=azure-devops&tabs=visual-studio-2019).
+To learn more see [Resolve merge conflicts](/azure/devops/repos/git/merging?view=azure-devops&tabs=visual-studio-2019&preserve-view=true).
 
 The following steps describe how reviewers of PRs in Azure Repos can navigate through a PR to understand the proposed changes:
 

release-notes/2022/includes/boards/sprint-212-update.md

@@ -20,11 +20,11 @@ We solved the problem by allowing you to edit and change the link type directly.
 
 We have seen several instances of extension authors attempting to run unsaved queries by passing the Work Item Query Language (WIQL) statement through the querystring. This works fine unless you have a large WIQL statement that reaches the browser limits on querystring length. To solve this, we have created a new REST endpoint to allow tool authors to generate a temporary query. Using the id from the response to pass via querystring eliminates this problem.
 
-Learn more at the [temp queries REST API documentation page](/rest/api/azure/devops/wit/temp-queries/create?view=azure-devops-rest-7.1).
+Learn more at the [temp queries REST API documentation page](/rest/api/azure/devops/wit/temp-queries/create?view=azure-devops-rest-7.1&preserve-view=true).
 
 ### Batch delete API (private preview)
 
-Currently, the only way to remove work items from the recycle bin is using this [REST API](/rest/api/azure/devops/wit/work-items/delete?view=azure-devops-rest-6.0&tabs=HTTP&viewFallbackFrom=azure-devops-rest-7.0) to delete one at a time. This can be a slow process and is subject to rate limiting when trying to do any kind of mass clean up. In response, we have added a new REST API endpoint to delete and/or destroy work items in batch.
+Currently, the only way to remove work items from the recycle bin is using this [REST API](/rest/api/azure/devops/wit/work-items/delete?view=azure-devops-rest-6.0&tabs=HTTP&viewFallbackFrom=azure-devops-rest-7.0&preserve-view=true) to delete one at a time. This can be a slow process and is subject to rate limiting when trying to do any kind of mass clean up. In response, we have added a new REST API endpoint to delete and/or destroy work items in batch.
 
 If you are interested in participating in a private preview of this new endpoint, please [email us directly](mailto:[email protected]).
 

release-notes/2022/includes/general/sprint-205-update.md

@@ -9,7 +9,7 @@ ms.topic: include
 
 Project Collection Administrators can now opt-in to receive notifications when a personal access token (PAT) belonging to a user in their organization is found in a GitHub public repository. 
 
-As a reminder, the Azure DevOps security team, in collaboration with our partners at GitHub, scan for Azure DevOps PATs [checked into public repositories on GitHub](https://devblogs.microsoft.com/devops/mitigating-leaked-personal-access-tokens-pats-found-on-github-public-repositories/) and sends an email notification to the owner of the token, if one is found in a GitHub public repository. This is also logged in the Azure DevOps organization's [Audit Log](/azure/devops/organizations/audit/azure-devops-auditing?view=azure-devops&tabs=preview-page#review-audit-log).
+As a reminder, the Azure DevOps security team, in collaboration with our partners at GitHub, scan for Azure DevOps PATs [checked into public repositories on GitHub](https://devblogs.microsoft.com/devops/mitigating-leaked-personal-access-tokens-pats-found-on-github-public-repositories/) and sends an email notification to the owner of the token, if one is found in a GitHub public repository. This is also logged in the Azure DevOps organization's [Audit Log](/azure/devops/organizations/audit/azure-devops-auditing?view=azure-devops&tabs=preview-page#review-audit-log&preserve-view=true).
 
 Project Collection Administrators can subscribe to these notifications by navigating to 
 **User Settings -> Notifications -> New Subscription**

release-notes/2022/includes/general/sprint-210-update.md

@@ -7,6 +7,6 @@ ms.topic: include
 
 ### All Public REST APIs support granular PAT scopes
 
-Previously, a number of publicly documented Azure DevOps REST APIs were not associated with scopes (e.g., work item read) that led to customers using full scopes to consume these APIs through non-interactive authentication mechanisms like personal access tokens (PAT). Using a full scope personal access token increases the risk when they can land in the hands of a malicious user. This is one of the main reasons that many of our customers did not take full advantage of the [control plane policies](/azure/devops/organizations/accounts/manage-pats-with-policies-for-administrators?view=azure-devops) to restrict the usage and behavior of the PAT. 
+Previously, a number of publicly documented Azure DevOps REST APIs were not associated with scopes (e.g., work item read) that led to customers using full scopes to consume these APIs through non-interactive authentication mechanisms like personal access tokens (PAT). Using a full scope personal access token increases the risk when they can land in the hands of a malicious user. This is one of the main reasons that many of our customers did not take full advantage of the [control plane policies](/azure/devops/organizations/accounts/manage-pats-with-policies-for-administrators?view=azure-devops&preserve-view=true) to restrict the usage and behavior of the PAT. 
 
-With this sprint release, all public Azure DevOps REST APIs are now associated with and support a granular PAT scope. If you are currently using a full-scoped PAT to authenticate to one of the public Azure DevOps REST APIs, consider migrating to a PAT with the specific scope accepted by the API to avoid unnecessary access. The supported granular PAT scope(s) for a given REST API can be found in the Security section of the [documentation pages](/rest/api/azure/devops/account/accounts/list?view=azure-devops-rest-7.1&tabs=HTTP#security). Additionally, there is a table of scopes [here](/azure/devops/integrate/get-started/authentication/oauth?view=azure-devops#scopes).
+With this sprint release, all public Azure DevOps REST APIs are now associated with and support a granular PAT scope. If you are currently using a full-scoped PAT to authenticate to one of the public Azure DevOps REST APIs, consider migrating to a PAT with the specific scope accepted by the API to avoid unnecessary access. The supported granular PAT scope(s) for a given REST API can be found in the Security section of the [documentation pages](/rest/api/azure/devops/account/accounts/list?view=azure-devops-rest-7.1&tabs=HTTP#security&preserve-view=true). Additionally, there is a table of scopes [here](/azure/devops/integrate/get-started/authentication/oauth?view=azure-devops#scopes&preserve-view=true).

release-notes/2022/includes/general/sprint-211-update.md

@@ -7,7 +7,7 @@ ms.topic: include
 
 ### Create personal access tokens to deploy to the Marketplace 
 
-We have resolved a [known issue](https://devblogs.microsoft.com/devops/issue-with-extension-publishing/) regarding publishing extensions to the Visual Studio Marketplace. If you’ve run into the error message: *Your ability to create global personal access tokens (PATs) is restricted by your organization.*, this is likely because your administrator has enabled [a policy to restrict the creation of global personal access tokens (PATs)](/azure/devops/organizations/accounts/manage-pats-with-policies-for-administrators?view=azure-devops#restrict-creation-of-global-pats).
+We have resolved a [known issue](https://devblogs.microsoft.com/devops/issue-with-extension-publishing/) regarding publishing extensions to the Visual Studio Marketplace. If you’ve run into the error message: *Your ability to create global personal access tokens (PATs) is restricted by your organization.*, this is likely because your administrator has enabled [a policy to restrict the creation of global personal access tokens (PATs)](/azure/devops/organizations/accounts/manage-pats-with-policies-for-administrators?view=azure-devops#restrict-creation-of-global-pats&preserve-view=true).
 
 > [!div class="mx-imgBorder"]
 > ![Create personal access tokens to deploy to Marketplace](../../media/211-general-01.png)

release-notes/2022/includes/pipelines/sprint-205-update.md

@@ -7,7 +7,7 @@ ms.topic: include
 
 ### Support Group Managed Service Accounts as agent service account
 
-The Azure Pipelines agent now supports Group Managed Service Accounts on [Self-hosted agents on Windows](/azure/devops/pipelines/agents/v2-windows?view=azure-devops).
+The Azure Pipelines agent now supports Group Managed Service Accounts on [Self-hosted agents on Windows](/azure/devops/pipelines/agents/v2-windows?view=azure-devops&preserve-view=true).
 
 [Group Managed Service Accounts (gSMAs)](https://aka.ms/gmsa) provide centralized password management for domain accounts that act as service accounts. The Azure Pipelines Agent can recognize this type of account so a password is not required during configuration:
 
@@ -35,7 +35,7 @@ Retrieving a pipeline's YAML code can fail due to:
 * Authentication issues
 * Unable to retrieve the content of the pipeline's .yml file
 
-Read more about [Informational runs](/azure/devops/pipelines/process/information-run?view=azure-devops).
+Read more about [Informational runs](/azure/devops/pipelines/process/information-run?view=azure-devops&preserve-view=true).
 
 ### Build Definition REST API `retentionRules` property is obsolete
 

release-notes/2022/includes/pipelines/sprint-206-update.md

@@ -9,4 +9,4 @@ ms.topic: include
 
 Azure Pipelines uses job access tokens to access other resources in Azure DevOps at run-time. A job access token is a security token that is dynamically generated by Azure Pipelines for each job at run time. Previously, when creating a new classic pipelines, the default value for the access token was set to **Project Collection**. With this update we are setting the job authorization scope to **current project** as the default when creating a new classic pipeline. 
 
-You can find more details about job access tokens in the [Access repositories, artifacts, and other resources documentation](/azure/devops/pipelines/process/access-tokens?view=azure-devops&tabs=classic).
+You can find more details about job access tokens in the [Access repositories, artifacts, and other resources documentation](/azure/devops/pipelines/process/access-tokens?view=azure-devops&tabs=classic&preserve-view=true).

release-notes/2022/includes/pipelines/sprint-207-update.md

@@ -13,7 +13,7 @@ For more information, see the [Integrate with ServiceNow Change Management docum
 
 ### Pipelines REST API Security Improvements
 
-Majority of the REST APIs in Azure DevOps use scoped PAT tokens. However, some of them require fully-scoped PAT tokens. In other words, you would have to create a PAT token by selecting 'Full access' in order to use some of these APIs. Such tokens pose a security risk since they can be used to call any REST API. We have been making improvements across Azure DevOps to remove the need for fully-scoped tokens by incorporating each REST API into a specific scope. As part of this effort, the [REST API to update pipeline permissions for a resource](/rest/api/azure/devops/approvalsandchecks/pipeline-permissions/update-pipeline-permisions-for-resources?view=azure-devops-rest-7.1) now requires a specific scope. The scope depends on the type of resource being authorized for use:
+Majority of the REST APIs in Azure DevOps use scoped PAT tokens. However, some of them require fully-scoped PAT tokens. In other words, you would have to create a PAT token by selecting 'Full access' in order to use some of these APIs. Such tokens pose a security risk since they can be used to call any REST API. We have been making improvements across Azure DevOps to remove the need for fully-scoped tokens by incorporating each REST API into a specific scope. As part of this effort, the [REST API to update pipeline permissions for a resource](/rest/api/azure/devops/approvalsandchecks/pipeline-permissions/update-pipeline-permisions-for-resources?view=azure-devops-rest-7.1&preserve-view=true) now requires a specific scope. The scope depends on the type of resource being authorized for use:
 
 * `Code (read, write, and manage)` for resources of type `repository`
 * `Agent Pools (read, manage)` or `Environment (read, manage)` for resources of type `queue` and `agentpool`
@@ -22,7 +22,7 @@ Majority of the REST APIs in Azure DevOps use scoped PAT tokens. However, some o
 * `Service Endpoints (read, query and manage)` for resources of type `endpoint`
 * `Environment (read, manage)` for resources of type `environment`
 
-To bulk edit pipelines permissions, you will still need a fully-scoped PAT token. To learn more about updating Pipeline permissions for resources, see the [Pipeline Permissions - Update Pipeline Permissions For Resources](/rest/api/azure/devops/approvalsandchecks/pipeline-permissions/update-pipeline-permisions-for-resources?view=azure-devops-rest-7.1) documentation. 
+To bulk edit pipelines permissions, you will still need a fully-scoped PAT token. To learn more about updating Pipeline permissions for resources, see the [Pipeline Permissions - Update Pipeline Permissions For Resources](/rest/api/azure/devops/approvalsandchecks/pipeline-permissions/update-pipeline-permisions-for-resources?view=azure-devops-rest-7.1&preserve-view=true) documentation. 
 
 ### Use proxy URLs for GitHub Enterprise integration
 
@@ -60,8 +60,8 @@ To help you better identify which pipelines are using the macOS-1015 image, we a
 
 ### Updates to "Run stage state changed" service hook event
 
-Service hooks let you run tasks on other services when events happen in your project in Azure DevOps, the [Run stage state changed](/azure/devops/service-hooks/events?view=azure-devops#run-stage-state-changed) is one of these events. The Run stage state changed event must contain information about the run including the name of the pipeline and the state of the overall run. Previously, it only included information about the id and name of the run. With this update, we made changes to the event to include missing information. 
+Service hooks let you run tasks on other services when events happen in your project in Azure DevOps, the [Run stage state changed](/azure/devops/service-hooks/events?view=azure-devops#run-stage-state-changed&preserve-view=true) is one of these events. The Run stage state changed event must contain information about the run including the name of the pipeline and the state of the overall run. Previously, it only included information about the id and name of the run. With this update, we made changes to the event to include missing information. 
 
 ### Change in the default scope of access tokens in classic build pipelines
 
-To improve the security of classic build pipelines, when creating a new one, the _build job authorization scope_ will be _Project_, by default. Until now, it used to be _Project Collection_. Read more about [Job access tokens](/azure/devops/pipelines/process/access-tokens?view=azure-devops&tabs=classic). This change does not impact any of the existing pipelines. It only impacts new classic build pipelines that you create from this point on.
+To improve the security of classic build pipelines, when creating a new one, the _build job authorization scope_ will be _Project_, by default. Until now, it used to be _Project Collection_. Read more about [Job access tokens](/azure/devops/pipelines/process/access-tokens?view=azure-devops&tabs=classic&preserve-view=true). This change does not impact any of the existing pipelines. It only impacts new classic build pipelines that you create from this point on.