Azure DevOpsServer 2020 Update 1 Release Notes

Developer Community | System Requirements | License Terms | DevOps Blog | SHA-1 Hashes

In this article, you will find information regarding the newest release for Azure DevOps Server.

To learn more about installing or upgrading an Azure DevOps Server deployment, see Azure DevOps Server Requirements. To download Azure DevOps products, visit the Azure DevOps Server Downloads page.

Direct upgrade to Azure DevOps Server 2020 is supported from Azure DevOps Server 2019 or Team Foundation Server 2015 or newer. If your TFS deployment is on TFS 2010 or earlier, you need to perform some interim steps before upgrading to Azure DevOps Server 2019. To learn more, see Install and configure Azure DevOps on-premises.

---

Safely Upgrade from Azure DevOps Server 2019 to Azure DevOps Server 2020

Azure DevOps Server 2020 introduces a new pipeline run (build) retention model that works based on project-level settings.

Azure DevOps Server 2020 handles build retention differently, based on pipeline-level retention policies. Certain policy configurations lead to pipeline runs being deleted after the upgrade. Pipeline runs that have been manually retained or are retained by a release will not be deleted after the upgrade.

Read our blog post for more information on how to safely upgrade from Azure DevOps Server 2019 to Azure DevOps Server 2020.

Azure DevOps Server 2020 Update 1.2 Patch 13 Release Date: March 12, 2024

File	SHA-256 Hash
devops2020.1.2patch13.exe	55B0A30EABD66EB22AA6093B7750EF3CFEFE79423018E304503CE728158F56F6

We have released Patch 13 for Azure DevOps Server 2020 Update 1.2 that includes fixes for the following:

• Resolved an issue where the Proxy Server stopped working after installing Patch 12.

Azure DevOps Server 2020 Update 1.2 Patch 12 Release Date: February 13, 2024

File	SHA-256 Hash
devops2020.1.2patch12.exe	C4C9EEBBDD3B07C36658C9F78AEA57A980AA633F99DF2A3AD5036F957F095E53

We have released Patch 12 for Azure DevOps Server 2020 Update 1.2 that includes fixes for the following:

• Fixed a bug where the disk space used by the proxy cache folder was calculated incorrectly and the folder was not properly cleaned up.
• CVE-2024-20667: Azure DevOps Server Remote Code Execution Vulnerability.

Azure DevOps Server 2020 Update 1.2 Patch 11 Release Date: December 12, 2023

File	SHA-256 Hash
devops2020.1.2patch11.exe	C47B9C898C2E08527F1DDC3E7A5E67F1A11C3AFF860DE9B5FF3DD8718C3AAE87

We have released Patch 11 for Azure DevOps Server 2020 Update 1.2 that includes fixes for the following:

• Fixed a bug where pre deployment approval security inheritance was not working in pipelines stages.

Azure DevOps Server 2020 Update 1.2 Patch 10 Release Date: November 14, 2023

We have released a patch for Azure DevOps Server 2020 Update 1.2 that includes fixes for the following.

• Extended the PowerShell tasks allowed list of characters for Enable shell tasks arguments parameter validation.

Note

To implement fixes for this patch you will have to follow a number of steps to manually update tasks.

Install patches

Important

We released updates to the Azure Pipelines agent with Patch 8 released on September 12, 2023. If you didn't install the agent updates as described in the release notes for Patch 8, we recommend that you install these updates before you install Patch 10. The new version of the agent after installing Patch 8 will be 3.225.0.

Configure TFX

1. Follow steps in the upload tasks to project collection documentation to install and login with tfx-cli.

Update tasks using TFX

File	SHA-256 Hash
Tasks20231103.zip	389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5

1. Download and extract Tasks20231103.zip.
2. Change directory into the extracted files.
3. Execute the following commands to upload the tasks:

tfx build tasks upload --task-zip-path AzureFileCopyV1.1.230.0.zip
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.230.0.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.230.0.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.230.0.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.230.0.zip 

Pipeline Requirements

To use the new behavior, a variable AZP_75787_ENABLE_NEW_LOGIC = true must be set in pipelines that use the affected tasks.

• On classic:

  Define the variable in the variable tab in the pipeline.

• YAML example:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server 2020 Update 1.2 Patch 9 Release Date: October 10, 2023

Important

We released updates to the Azure Pipelines agent with Patch 8 released on September 12, 2023. If you didn't install the agent updates as described in the release notes for Patch 8, we recommend that you install these updates before you install Patch 9. The new version of the agent after installing Patch 8 will be 3.225.0.

We have released a patch. for Azure DevOps Server 2020 Update 1.2 that includes fixes for the following.

• Fixed a bug where "Analysis Owner" identity shows as Inactive Identity on patch upgrade machines.

Azure DevOps Server 2020 Update 1.2 Patch 8 Release Date: September 12, 2023

We have released a patch for Azure DevOps Server 2020 Update 1.2 that includes fixes for the following.

• CVE-2023-33136: Azure DevOps Server Remote Code Execution Vulnerability.
• CVE-2023-38155: Azure DevOps Server and Team Foundation Server Elevation of Privilege Vulnerability.

Important

Please deploy the patch to a test environment and ensure that the environment’s pipelines work as expected before applying the fix to production.

Note

To implement fixes for this patch you will have to follow a number of steps to manually update the agent and tasks.

Install patches

1. Download and install Azure DevOps Server 2020 Update 1.2 patch 8.

Update the Azure Pipelines agent

1. Download the agent from: https://github.com/microsoft/azure-pipelines-agent/releases/tag/v3.225.0 - Agent_20230825.zip
2. Use the steps outlined in the self-hosted Windows agents documentation to deploy the agent.  

Note

The AZP_AGENT_DOWNGRADE_DISABLED must be set to “true” to prevent the agent from being downgraded. On Windows, the following command can be used in an administrative command prompt, followed by a reboot. setx AZP_AGENT_DOWNGRADE_DISABLED true /M

Configure TFX

1. Follow steps in the upload tasks to project collection documentation to install and login with tfx-cli.

Update tasks using TFX

1. Download and extract Tasks_20230825.zip.
2. Change directory into the extracted files.
3. Execute the following commands to upload the tasks:

tfx build tasks upload --task-zip-path AzureFileCopyV1.1.226.3.zip
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.226.2.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.226.1.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.226.2.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.226.2.zip 

Pipeline Requirements

To use the new behavior, a variable AZP_75787_ENABLE_NEW_LOGIC = true must be set in pipelines that use the affected tasks.

• On classic:

  Define the variable in the variable tab in the pipeline.

• YAML example:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server 2020 Update 1.2 Patch 7 Release Date: August 8, 2023

We have released a patch for Azure DevOps Server 2020 Update 1.2 that includes fixes for the following.

• CVE-2023-36869: Azure DevOps Server Spoofing Vulnerability.
• Update SSH service to support SHA2-256 and SHA2-512. If you have SSH config files hard coded to use RSA, you should update to SHA2 or remove the entry.
• Addressed issue with relative links not working in markdown files.
• Fixed a bug with comment navigation on a commit page.
• Fixed a bug where Analysis Owner identity showed as Inactive Identity.
• Fixed infinite loop bug on CronScheduleJobExtension.

Azure DevOps Server 2020 Update 1.2 Patch 6 Release Date: June 13, 2023

We have released a patch for Azure DevOps Server 2020 Update 1.2 that includes fixes for the following.

• CVE-2023-21565: Azure DevOps Server Spoofing Vulnerability.
• CVE-2023-21569: Azure DevOps Server Spoofing Vulnerability.
• Fixed a bug that interfered with pushing packages when upgrading from 2018 or earlier.
• Fixed a bug where detach or attach collection fails reporting the following error: 'TF246018: The database operation exceeded the timeout limit and has been cancelled.

Azure DevOps Server 2020 Update 1.2 Patch 5 Release Date: February 14, 2023

We have released a patch for Azure DevOps Server 2020 Update 1.2 that includes fixes for the following.

• CVE-2023-21553: Azure DevOps Server Remote Code Execution Vulnerability
• Fixed shelvesets accessibility issue via web UI
• Customers need to restart tfsjobagent service and Azure DevOps Server application pool after updating SMTP-related setting in the Azure DevOps Server Management Console.

Azure DevOps Server 2020 Update 1.2 Patch 4 Release Date: December 13, 2022

We have released a patch for Azure DevOps Server 2020 Update 1.2 that includes fixes for the following.

• Fixed display of special characters in the IdentityPicker.

• Test data was not being deleted, causing the database to grow. With this fix, we updated build retention to prevent creating new orphan test data.

Azure DevOps Server 2020 Update 1.2 Patch 3 Release Date: October 18, 2022

We have released a patch for Azure DevOps Server 2020 Update 1.2 that includes fixes for the following.

• Resolve issue with newly added AD identities not appearing in security dialog identity pickers.
• Fix an issue with Requested by Member of Group filter in the web hook settings.
• Fix Gated check-in builds error when the Organization settings for pipeline had job authorization scope configured as Limit job authorization scope to current project for non-release pipelines.
• Fix retrieving access token from Azure when establishing service connection behind authenticated proxy.

Azure DevOps Server 2020 Update 1.2 Patch 2 Release Date: August 9, 2022

We have released a patch for Azure DevOps Server 2020 Update 1.2 that includes fixes for the following.

• Fix identity value error while assigning a work item to an identity which appears in different domains.

Azure DevOps Server 2020 Update 1.2 Patch 1 Release Date: July 12, 2022

We have released a patch for Azure DevOps Server 2020 Update 1.2 that includes fixes for the following.

• In Test Runs APIs, the continuation token being returned was greater than the “maxLastUpdatedDate” value that was specified.

Azure DevOps Server 2020 Update 1.2 Release Date: May 17, 2022

Azure DevOps Server 2020 Update 1.2 is a roll up of bug fixes. You can directly install Azure DevOps Server 2020 Update 1.2 or upgrade from Azure DevOps Server 2020 or Team Foundation Server 2013 or newer.

Note

The Data Migration Tool will be available for Azure DevOps Server 2020 Update 1.2 about three weeks after this release. You can see our list of currently supported versions for import here.

This release includes fixes for the following:

• Azure DevOps Server 2020.1.2 disables the new retention model (introduced in Azure DevOps Server 2020), to prevent loss of pipeline runs (builds). This means the system will:

  • Create leases for the most recent 3 builds generated while running Server 2020
  • For YAML pipelines and Classic pipelines without per-pipeline retention policies, builds will be retained according to the collection-level maximum retention settings
  • For Classic pipelines with custom per-pipeline retention policies, builds will be retained according to the pipeline-specific retention policy
  • The builds with leases do not count toward the Minimum to keep setting

• Changeset and shelveset comments links were not redirecting properly. When comments were added to files in changesets or shelvesets, selecting those comments were not redirecting to the correct place in the file view.

• Unable to skip build queue using the the "Run next" button. Previously, the "Run next" button was enabled for project collection administrators only.

• Revoke all personal access tokens after a user's Active Directory account is disabled.

Azure DevOps Server 2020.1.1 Patch 4 Release Date: January 26, 2022

We have released a patch for Azure DevOps Server 2020.1.1 that includes fixes for the following.

• Email notifications were not sent when using the @mention control in a work item.
• Preferred email address was not getting updated in user profile. This resulted in emails being sent to the previous email address.
• Header was not shown in the Project Summary page. The header was shown for a few milliseconds and then it disappeared.
• Improvement to Active Directory user sync.
• Addressed Elasticsearch vulnerability by removing the jndilookup class from log4j binaries.

Installation steps

1. Upgrade the server with Patch 4.
2. Check the registry value at HKLM:\Software\Elasticsearch\Version. If the registry value is not there, add a string value and set the Version to 5.4.1 (Name = Version, Value = 5.4.1).
3. Run the update command PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation update as provided in the readme file. It may return a warning like: Unable to connect to the remote server. Don't close the window, as the update is performing retries until it is completed.

Note

If Azure DevOps Server and Elasticsearch are installed on different machines, follow the steps outlined below.

1. Upgrade the server with Patch 4.
2. Check the registry value at HKLM:\Software\Elasticsearch\Version. If the registry value is not there, add a string value and set the Version to 5.4.1 (Name = Version, Value = 5.4.1).
3. Copy the content of the folder named zip, located on C:\Program Files\{TFS Version Folder}\Search\zip to the Elasticsearch remote file folder.
4. Run Configure-TFSSearch.ps1 -Operation update on the Elasticsearch server machine.

SHA-256 Hash: 451F0BB73132EFCD2B3D2922F0040DBF2BCF2808C35D3C37CA5A3CD8F65F29D6

Azure DevOps Server 2020.1.1 Patch 3 Release Date: December 15, 2021

Patch 3 for Azure DevOps Server 2020.1.1 includes fixes for the following.

• Fix work item macro for queries with "Contains Words". Previously, queries were returning incorrect results for values that contained a line break.
• Increase limits for Maven package version character length.
• Localization issue for custom work items layout states.
• Localization issue in email notification template.
• Issue with NOTSAMEAS rules evaluation when multiple NOTSAMEAS rules were defined for a field.

Azure DevOps Server 2020.1.1 Patch 2 Release Date: October 26, 2021

Patch 2 for Azure DevOps Server 2020.1.1 includes fixes for the following.

• Previously, Azure DevOps Server could only create connections to GitHub Enterprise Server. With this patch, project administrators can create connections between Azure DevOps Server and repositories on GitHub.com. You can find this setting in the GitHub connections page under Project Settings.
• Resolve issue with Test Plan widget. The test execution report was showing an incorrect user on results.
• Fix issue with the Project Overview summary page failing to load.
• Fix issue with emails not being sent to confirm product upgrade.

Azure DevOps Server 2020.1.1 Patch 1 Release Date: September 14, 2021

Patch 1 for Azure DevOps Server 2020.1.1 includes fixes for the following.

• Fix Artifacts download/upload failure.
• Resolve issue with inconsistent Test Results data.

Azure DevOps Server 2020 Update 1.1 Release Date: August 17, 2021

Azure DevOps Server 2020 Update 1.1 is a roll up of bug fixes. You can directly install Azure DevOps Server 2020 Update 1.1 or upgrade from Azure DevOps Server 2020 or Team Foundation Server 2013 or newer.

Note

The Data Migration Tool will be available for Azure DevOps Server 2020 Update 1.1 about three weeks after this release. You can see our list of currently supported versions for import here.

This release includes fixes for the following bugs:

Azure Boards

• The "View work item" hyperlink in the notification emails is not using the public URL.

Azure Repos

• Fixed limited merge types inheritance checkboxes display to enable modify limit merge types after setting cross-reposity policies.

Azure Pipelines

• When changing the setting for Agent Update, settings were not propagating to other application tiers in the environment.

General

• Fixed spelling in server configuration wizard.
• Increased extension package size and allow for you to change the size in registry.

Azure Test Plans

• Unable to navigate back to test results once you hit back from history to summary page.

---

Azure DevOps Server 2020.1 Patch 2 Release Date: August 10, 2021

We have released a patch for Azure DevOps Server 2020.1 that fixes the following.

• Fix build definition UI error.
• Changed browsing history to display files instead of the root repository.

Azure DevOps Server 2020.1 Patch 1 Release Date: June 15, 2021

We have released a patch for Azure DevOps Server 2020.1 that fixes the following.

• Secure cookies used in authorization flows that assert SameSite=None.

• Resolve issue with Notifications SDK. Previously, notifications subscriptions using the Area Path filter were not being parsed correctly.

Azure DevOps Server 2020.1 RTW Release Date: May 25, 2021

Summary of What's New in Azure DevOps Server 2020.1 RTW

Azure DevOps Server 2020.1 RTW is a roll up of bug fixes. It includes all features in the Azure DevOps Server 2020.1 RC2 previously released. Azure DevOps Server 2020.1 RTW is a roll up of bug fixes. You can directly install Azure DevOps Server 2020.1 or upgrade from Azure DevOps Server 2020, 2019 or Team Foundation Server 2015 or newer.

Note

The Data Migration Tool will be available for Azure DevOps Server 2020 Update 1 about three weeks after this release. You can see our list of currently supported versions for import here.

Azure DevOps Server 2020.1 RC2 Release Date: April 13, 2021

Summary of What's New in Azure DevOps Server 2020.1 RC2

Azure DevOps Server 2020.1 RC2 is a roll up of bug fixes. It includes all features in the Azure DevOps Server 2020.1 RC1 previously released.

Azure DevOps Server 2020.1 RC1 Release Date: March 23, 2021

Summary of What's New in Azure DevOps Server 2020.1 RC1

Azure DevOps Server 2020.1 RC1 introduces many new features. Some of the highlights include:

• State transition restriction rules in Boards
• Stakeholders can now move work items across board columns
• Improve release security by restricting scope of access tokens
• Enhanced pull request experience
• Multi-repo triggers in Pipelines

You can also jump to individual sections to see all the new features for each service:

• Boards
• Repos
• Pipelines
• Artifacts

---

Boards

State transition restriction rules

We continue to close the feature parity gap between hosted XML and the inherited process model. This new work item type rule lets you restrict work items from being moved from one state to another. For example, you can restrict Bugs from going from New to Resolved. Instead, they must go from New –> Active -> Resolved

You can also create a rule to restrict state transitions by group membership. For example, only users in the “Approvers” group can move user stories from New -> Approved.

Copy work item to copy children

One of the top requested features for Azure Boards is the ability to copy a work item that also copies the child work items. We added a new option to "Include child work items" to the copy work item dialog. When selected, this option will copy the work item and copy all child work items (up to 100).

Improved rules for activated and resolved fields

Up until now, the rules for Activated By, Activated Date, Resolved By, and Resolved Date have been a mystery. They are only set for system work item types and are specific to the state value of "Active" and "Resolved". We've changed the logic so that these rules are no longer for a specific state. Instead, they are triggered by the category (state category) that the state resides in. For example, let's say you have a custom state of "Needs Testing" in the Resolved category. When the work item changes from "Active" to "Needs Testing", the Resolved By and Resolved Date rules are triggered.

This allows customers to create any custom state values and still generate the Activated By, Activated Date, Resolved By, and Resolved Date fields, without the need to use custom rules.

Stakeholders can move work items across board columns

Stakeholders have always been able to change the state of work items. But when they go to the Kanban board, they're unable to move the work items from one column to another. Instead, Stakeholders would have to open each work item, one at a time, and update the state value. This has long been a pain point for customers, and we're happy to announce that you can now move work items across board columns.

System work item types on backlogs and boards

Now you can add a system work item type to the backlog level of choice. Historically these work item types have only been available from queries.

Process	Work Item Type
Agile	Issue
Scrum	Impediment
CMMI	Change Request
	Issue
	Review
	Risk

Adding a system work item type to a backlog level is simple. Just go into your custom process and click the Backlog Levels tab. Select your backlog level of choice (example: Requirements Backlog) and choose the edit option. Then add the work item type.

Azure Boards GitHub app repo limit raised

The repo limit for the Azure Boards application in the GitHub marketplace has been increased from 100 to 250.

Customize work item state when pull request is merged

Not all workflows are the same. Some customers want to close out their related work items when a Pull Request is completed. Others want to set the work items to another state to be validated before closing. We should allow for both.

We have a new feature that allows you to set the work items to the desired state when the pull request is merged and completed. To do this, we scan the pull request description and look for the state value followed by the #mention of the work item(s). In this example, we are setting two user stories to Resolved and closing two tasks.

Link your work item to builds in another project

You can now easily track your build dependencies across project just by linking your work item to a Build, Found in build, or Integrated in build.

Editing description (help text) on system fields

You have always been able to edit the description of custom fields. But for system fields like priority, severity, and activity, the description was not editable. This was a feature gap between the Hosted XML and Inherited that prevented some customers from migrating to the Inherited model. You can now edit the description on system fields. The edited value will only affect that field in the process and for that work item type. This gives you the flexibility to have different descriptions for the same field on different work item types.

Customize work item state when pull request is merged

Pull requests often refer to multiple work items. When you create or update a pull request, you may want to close some of them, resolve some of them, and keep the rest open. You can now use comments such as the ones shown in the figure below to accomplish that. See documentation for more details.

Parent field on the task board

Due to popular request, you can now add the Parent field to both the child and parent cards on the Task Board.

Removing "Assigned To" rule on Bug work item type

There are several hidden system rules across all the different work item types in Agile, Scrum, and CMMI. These rules have existed for over a decade and have generally worked fine without any complaints. However, there are a couple of rules that have run out their welcome. One rule in particular has caused a lot of pain for new and existing customers and we have decided it was time to remove it. This rule exists on the Bug work item type in the Agile process.

"Set the Assigned value to Created By when state is changed to Resolved"

We received a lot of your feedback about this rule. In response, we went ahead and removed this rule from the Bug work item type in the Agile process. This change will affect every project using an inherited Agile or a customized inherited Agile process. For those customers who like and depend on this current rule, please see our blog post on the steps you can take to re-add the rule in using custom rules.

Removed items on the Work Items page

The Work Items page is a great place to quickly find items you created or that are assigned to you, amongst other things. It provides several personalized pivots and filters. One of the top complaints for the "Assigned to me" pivot is that it displays Removed work items (that is, work items in the Removed state). And we agree! Removed items are work that is no longer of value and thus has been removed from the backlog, so including it in this view is not helpful.

You can now hide all Removed items from the Assigned to me pivot on the Work Items page.

Repos

Default branch name preference

Azure Repos now offers a customizable default branch name for Git. In repository settings, you may choose any legal branch name to use when a repository is initialized. Azure Repos has always supported changing the default branch name for an existing repository. Visit Manage branches for more details.

 

Note: if you don't enable this feature, your repositories will be initialized with Azure Repos's default name. Right now, that default is master. To honor Microsoft's commitment to, and customer requests for, inclusive language, we'll be joining industry peers in changing this default to main. That change will occur later this summer. If you want to keep using master, you should turn on this feature now and set it to master.

Org-level setting for default branch

There is now an collection-level setting for your preferred initial branch name for new repositories. If a project has not chosen an initial branch name, then this org-level setting will be used. If you did not specify the initial branch name in the org settings or the project settings, then new repositories will use an Azure DevOps defined default.

Add a new auth scope for contributing PR comments

This release adds a new OAuth scope for reading/writing pull request comments. If you have a bot or automation which only needs to interact with comments, you can give it a PAT with only this scope. This process reduces the blast radius if the automation has a bug or if the token were compromised.

Pull Request experience improvements

The new pull request experience has been improved with the following:

• Make the optional checks more visible

Customers use optional checks to draw a developer's attention to potential issues. In the previous experience, it used to be obvious when these checks fail. However, that is not the case in the preview experience. A big, green checkmark on the required checks masks the failures in optional checks. Users could only discover that optional checks failed by opening the checks panel. Developers don't often do that when there is no indication of a problem. In this deployment, we made the status of optional checks more visible in the summary.

• Ctrl-clicks on menu items

Tab menus on a PR didn't support Ctrl-click. Users often open new browser tabs as they review a pull request. This has been fixed.

• Location of [+] annotation

The tree listing of files in a PR shows an annotation [+] to help authors and reviewers identify new files. Since the annotation was after the ellipsis, it was often not visible for longer file names.

• PR updates dropdown regain timing information

The dropdown to select update and compare files in a PR lost an important element in the preview experience. It didn't show when that update was made. This has been fixed.

• **Improved comment filter layout **

When filtering comments on the summary page of a pull request, the drop-down was on the right, but the text was left-aligned. This has been fixed.

• Navigation to parent commits

Under the Commits page, you can compare the changes made in a particular commit with its parent commit. However, you may want to navigate to the parent commit and further understand how that commit differs from its own parent. This is often needed when you want to understand all the changes in a release. We added a parent(s) card to a commit to help you achieve this.

• More space for folders and files with long names in the PR files tab

Folders and files with long names were cut off due to a lack of horizontal spacing in the file tree. We recovered some additional space in the tree by modifying the tree’s indentation to match the root node and by hiding the ellipsis button from the page except on hover.

Image of the new file tree:

Image of the file tree when hovering over a directory:

• Preserve scroll position when resizing diff pane in PR files tab

When resizing the side-by-side diff pane in the PR files tab, the user’s scroll location would be lost. This issue has been fixed; the user’s scroll location is now retained on a diff pane resize.

• Search for a commit on a mobile device

When viewing the Commits page on a mobile device, the search box is missing in the new experience. As a result, it is hard for you to find a commit by its hash and open it. This has been fixed now.

• Improved usage of space for new PR file diff mobile view

We updated this page to make better use of the space so that users can see more of the file in mobile views instead of having 40% of the screen taken up by a header.

• Enhanced images in PR summary view

Images edited in a PR were not showing in the PR summary view but did show correctly in the PR files view. This issue has been resolved.

• Enhanced branch experience when creating a new PR

Before this update, this experience was not ideal as it would compare the changes with the default branch of the repository instead of the compare branch.

Pipelines

Additional agent platform: ARM64

We added Linux/ARM64 to the list of supported platforms for the Azure Pipelines agent. Although the code changes were minimal, a lot of behind-the-scenes work had to be completed first, and we're excited to announce its release!

Tag filter support for pipeline resources

We have now added 'tags' in YAML pipelines. You can use tags to set the CI pipeline to run or when to automatically trigger.

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    branch: master
    tags:              ### This filter is used for resolving default version
    - Production       ### Tags are AND'ed
    trigger:
      tags:            ### This filter is used for triggering the pipeline run
      - Production     ### Tags are AND'ed
      - Signed

The above snippet shows that tags can be used to determine the default version of the CI (continuous integration) pipeline to run when the CD (continuous deployment) pipeline run is not triggered by some other source/resource or a scheduled run trigger.

For instance, if you have a scheduled trigger set for your CD pipeline that you only want to run if your CI has the production tag, the tags in the triggers section ensures that the CD pipeline is only triggered if the tagging condition is met by the CI completion event.

Control which tasks are allowed in pipelines

You can now disable Marketplace tasks. Some of you may allow Marketplace extensions, but not the Pipelines tasks they bring along. For even more control, we also allow you to independently disable all in-the-box tasks (except checkout, which is a special action). With both of these settings enabled, the only tasks allowed to run in a pipeline would be those uploaded using tfx. Visit https://dev.azure.com/<your_org>/_settings/pipelinessettings and look for the section called "Task restrictions" to get started.

Exclusive deployment lock policy

With this update, you can ensure that only a single run deploys to an environment at a time. By choosing the "Exclusive lock" check on an environment, only one run will proceed. Subsequent runs which want to deploy to that environment will be paused. Once the run with the exclusive lock completes, the latest run will proceed. Any intermediate runs will be canceled.

Stages filters for pipeline resource triggers

We added support for 'stages' as a filter for pipeline resources in YAML. With this filter, you don't need to wait for the entire CI pipeline to be completed to trigger your CD pipeline. You can now choose to trigger your CD pipeline upon completion of a specific stage in your CI pipeline.

resources:
  pipelines:
  - pipeline: MyCIAlias  
    project: Fabrikam  
    source: Farbrikam-CI  
    trigger:    
      stages:            ### This stage filter is used when evaluating conditions for triggering your CD pipeline
      - PreProduction    ### stages are AND'ed. On successful completion of all the stages provided, your CD pipeline will be triggered. 
      - Production

When the stages provided in the trigger filter are successfully completed in your CI pipeline, a new run is automatically triggered for your CD pipeline.

Generic webhook based triggers for YAML pipelines

Today, we have various resources (such as pipelines, containers, build, and packages) through which you can consume artifacts and enable automated triggers. Until now, however, you could not automate your deployment process based on other external events or services. In this release, we are introducing webhook trigger support in YAML pipelines to enable integration of pipeline automation with any external service. You can subscribe to any external events through its webhooks (Github, Github Enterprise, Nexus, Aritfactory, etc.) and trigger your pipelines.

Here are the steps to configure the webhook triggers:

1. Setup a webhook on your external service. When creating your webhook, you need to provide the following info:

   • Request Url - "https://dev.azure.com/<ADO collection>/_apis/public/distributedtask/webhooks/<WebHook Name>?api-version=6.0-preview"
   • Secret - This is optional. If you need to secure your JSON payload, provide the Secret value

2. Create a new "Incoming Webhook" service connection. This is a newly introduced Service Connection Type that will allow you to define three important pieces of information:

   • Webhook Name: The name of the webhook should match webhook created in your external service.
   • HTTP Header - The name of the HTTP header in the request that contains the payload hash value for request verification. For example, in the case of the GitHub, the request header will be "X-Hub-Signature"
   • Secret - The secret is used to parse the payload hash used for verification of the incoming request (this is optional). If you have used a secret in creating your webhook, you will need to provide the same secret key

   

3. A new resource type called webhooks is introduced in YAML pipelines. For subscribing to a webhook event, you need to define a webhook resource in your pipeline and point it to the Incoming webhook service connection. You can also define additional filters on the webhook resource based on the JSON payload data to further customize the triggers for each pipeline, and you can consume the payload data in the form of variables in your jobs.

resources:
  webhooks:
    - webhook: MyWebhookTrigger          ### Webhook alias
      connection: MyWebhookConnection    ### Incoming webhook service connection
      filters:
        - path: repositoryName      ### JSON path in the payload
          value: maven-releases     ### Expected value in the path provided
        - path: action
          value: CREATED
steps:
- task: PowerShell@2
  inputs:
    targetType: 'inline'
    ### JSON payload data is available in the form of ${{ parameters.<WebhookAlias>.<JSONPath>}}
    script: |
      Write-Host ${{ parameters.MyWebhookTrigger.repositoryName}}
      Write-Host ${{ parameters.MyWebhookTrigger.component.group}}

4. Whenever a webhook event is received by the Incoming Webhook service connection, a new run will be triggered for all the pipelines subscribed to the webhook event.

YAML resource trigger issues support and traceability

It can be confusing when pipeline triggers fail to execute as you expect them to. To help better understand this, we've added a new menu item in the pipeline definition page called 'Trigger Issues' where information is surfaced regarding why triggers are not executing.

Resource triggers can fail to execute for two reasons.

1. If the source of the service connection provided is invalid, or if there are any syntax errors in the trigger, the trigger will not be configured at all. These are surfaced as errors.

2. If trigger conditions are not matched, the trigger will not execute. Whenever this occurs, a warning will be surfaced so you can understand why the conditions were not matched.

   

Multi-repo triggers

You can specify multiple repositories in one YAML file and cause a pipeline to trigger by updates to any of the repositories. This feature is useful, for instance, in the following scenarios:

• You consume a tool or a library from a different repository. You want to run tests for your application whenever the tool or library is updated.
• You keep your YAML file in a separate repository from the application code. You want to trigger the pipeline every time an update is pushed to the application repository.

With this update, multi-repo triggers will only work for Git repositories in Azure Repos. They don't work for GitHub or BitBucket repository resources.

Here is an example that shows how to define multiple repository resources in a pipeline and how to configure triggers on all of them.

trigger:
- main

resources:
  repositories:
  - repository: tools
    type: git
    name: MyProject/tools
    ref: main
    trigger:
      branches:
        include:
        - main
        - release

The pipeline in this example will be triggered if there are any updates to:

• main branch in the self repo containing the YAML file
• main or release branches in tools repo

For more information, see Multiple repositories in your pipeline.

Agent log uploads improved

When an agent stops communicating with the Azure Pipelines server, the job it was running becomes abandoned. If you happened to be looking at the streaming console logs, you might have gotten some clues about what the agent was up to right before it stopped responding. But if you weren't, or if you refreshed the page, those console logs were gone. With this release, if the agent stops responding before it sends up its full logs, we'll keep the console logs as the next-best thing. Console logs are limited to 1000 characters per line and can occasionally be incomplete, but they're a lot more helpful than showing nothing! Examining these logs may help you troubleshoot your own pipelines, and it will certainly help our support engineers when they assist with troubleshooting.

Optionally mount container volumes read-only

When you run a container job in Azure Pipelines, several volumes containing the workspace, tasks, and other materials are mapped as volumes. These volumes default to read/write access. For increased security, you can mount the volumes read-only by altering your container specification in YAML. Each key under mountReadOnly can be set to true for read-only (the default is false).

resources:
  containers:
    - container: example
      image: ubuntu:18.04
      mountReadOnly:
        externals: true
        tasks: true
        tools: true
        work: false

Fine-grained control over container start/stop

In general, we recommend that you allow Azure Pipelines to manage the lifecycle of your job and service containers. However, in some uncommon scenarios, you may want to start and stop them yourself. With this release, we've built that capability into the Docker task.

Here's an example pipeline using the new capability:

resources:
  containers:
    - container: builder
      image: ubuntu:18.04
steps:
  - script: echo "I can run inside the container (it starts by default)"
    target:
      container: builder
  - task: Docker@2
    inputs:
      command: stop
      container: builder
# if any step tried to run in the container here, it would fail

Also, we include the list of containers in a pipeline variable, Agent.ContainerMapping. You can use this if you want to inspect the list of containers in a script, for example. It contains a stringified JSON object mapping the resource name ("builder" from the example above) to the container ID the agent manages.

Unzip task bundles for each step

When the agent runs a job, it first downloads all the task bundles required by the job's steps. Normally, for performance, it unzips the tasks once per job even if the task is used in multiple steps. If you have concerns about untrusted code altering the unzipped contents, you can trade away a little bit of performance by having the agent unzip the task on each usage. To enable this mode, pass --alwaysextracttask when configuring the agent.

Improve release security by restricting scope of access tokens

Building upon our initiative to enhance security settings for Azure Pipelines, we now support restricting scope of access tokens for releases.

Every job that runs in releases gets an access token. The access token is used by the tasks and by your scripts to call back into Azure DevOps. For example, we use the access token to get source code, download artifacts, upload logs, test results, or to make REST calls into Azure DevOps. A new access token is generated for each job, and it expires once the job completes.

With this update, we build upon improve pipeline security by restricting the scope of access tokens and extend the same to classic releases.

This feature will be on by default for new projects and collections. For existing collections, you must enable it in collection Settings > Pipelines > Settings. > Limit job authorization scope to current project for release pipelines. Learn more here.

YAML preview API enhancements

You can now preview the complete YAML of a pipeline without running it. In addition, we've created a dedicated new URL for the preview capability. Now you can POST to https://dev.azure.com/{collection}/{project}/_apis/pipelines/{pipelineId}/preview to retrieve the finalized YAML body. This new API takes the same parameters as queuing a run, but no longer requires the "Queue builds" permission.

Run this job next

Have you ever had a bugfix which you needed to deploy right this minute but had to wait behind CI and PR jobs? With this release, we now allow you to bump the priority of a queued job. Users with the "Manage" permission on the pool - typically pool administrators - will see a new "Run next" button on the job details page. Clicking the button will set the job to be run as soon as possible. (You'll still need available parallelism and a suitable agent, of course.)

Template expressions allowed in YAML resources block

Previously, compile-time expressions (${{ }}) were not allowed in the resources section of an Azure Pipelines YAML file. With this release, we have lifted this restriction for containers. This allows you to use runtime parameter contents inside your resources, for example to pick a container at queue time. We plan to extend this support to other resources over time.

Control over automated task updates from Marketplace

When you write a YAML pipeline, normally you specify only the major version number of the included tasks. This allows your pipelines to automatically take the latest feature additions and bug fixes. Occasionally you may need to roll back to a previous point release of a task, and with this update, we added the ability for you to do so. You may now specify a full major.minor.patch task version in your YAML pipelines.

We don't recommend that you do this regularly, and use it only as a temporary workaround when you find that a newer task breaks your pipelines. Also, this will not install an older version of a task from the Marketplace. It must already exist in your collection or your pipeline will fail.

Example:

steps:
- task: MyTask@1  # a normal, major-version only reference
- task: MyOtherTask@2.3.4   # pinned to a precise version

Node 10 support in agent and tasks

Since Node 6 is no longer supported, we are migrating the tasks to work with Node 10. For this update, we have migrated nearly 50% of in-box tasks to Node 10. The agent can now run both Node 6 and Node 10 tasks. In a future update, we will entirely remove Node 6 from the agent. To prepare for the removal of Node 6 from the agent, we request that you update your in-house extensions and custom tasks to also use Node 10 soon. To use Node 10 for your task, in your task.json, under execution, update from Node to Node10.

Improve YAML conversion in the classic build designer

With this release, we introduce a new "export to YAML" feature for designer build pipelines. Save your pipeline definition, then find "Export to YAML" on the ... menu.

The new export function replaces the "View as YAML" function previously found in the classic build designer. That function was incomplete as it could only inspect what the web UI knew about the build, which sometimes led to incorrect YAML being generated. The new export function takes into account exactly how the pipeline will be processed and generates YAML with full fidelity to the designer pipeline.

New web platform conversion – Repository settings

We have converted the two Repository settings pages to a single experience that was upgraded to a new web platform. This upgrade not only makes the experience faster and more modern, but these pages also provide a single entry-point for all policies from the project level to the branch level.

With this new experience, navigation for projects with a substantial number of repositories has become easier because of faster load times and an added search filter. You can also view project level policies and the list of cross-repo policies under the Policies tab.

If you click into a repository, you can view policies and permissions set at the repository level. Within the policies tab, you can view a list of every branch that policy is set on. Now, click on the branch to see the policies all while never leaving the Repository settings page.

Now, when policies are inherited from a higher scope than what you are working with, we show you where the policy was inherited from next to each individual policy. You can also navigate to the page where the higher-level policy was set by clicking the scope name.

The policy page itself has also been upgraded to the new web platform with collapsible sections! To improve the experience of looking for a particular Build Validation, Status Check, or Automatic Reviewer policy, we have added search filters for each section.

ServiceNow change management integration with YAML pipelines

The Azure Pipelines app for ServiceNow helps you integrate Azure Pipelines and ServiceNow Change Management. With this update, we take our journey of making Azure Pipelines aware of the change management process managed in ServiceNow further to YAML pipelines.

By configuring the "ServiceNow Change Management" check on a resource, you can now pause for the change to be approved before deploying the build to that resource. You can automatically create a new change for a stage or wait on an existing change request.

You can also add the UpdateServiceNowChangeRequest task in a server job to update the change request with deployment status, notes etc.

Artifacts

Ability to create org-scoped feeds from UI

We are bringing back the ability for customers to create and manage collection-scoped feeds through the web UI for both on-prem and hosted services.

You can now create org-scoped feeds via the UI, by going to Artifacts -> Create Feed and choosing a type of feed within Scope.

While we do recommend the usage of project-scoped feeds in alignment with the rest of Azure DevOps offerings, you can again create, manage, and use collection-scoped feeds via UI and various REST APIs. Please see our feeds documentation for more information.

Update Package Version REST API now available for Maven packages

You can now use the Azure Artifacts "Update Package Version" REST API to update Maven package versions. Previously, you could use the REST API to update package versions for NuGet, Maven, npm, and Universal Packages, but not Maven packages.

To update Maven packages, use the HTTP PATCH command as follows.

PATCH https://pkgs.dev.azure.com/{collection}/{project?}/\_apis/packaging/feeds/{feedId}/maven/groups/{groupId}/artifacts/{artifactId}/versions/{packageVersion}?api-version=5.1-preview.1

You can set the following:

URI Parameters

Name	In	Required	Type	Description
artifactId	path	TRUE	string	Artifact ID of the package
feed	path	TRUE	string	Name or ID of the feed
groupId	path	TRUE	string	Group ID of the package
collection	path	TRUE	string	The name of the Azure DevOps collection
version	path	TRUE	string	Version of the package
project	path		string	Project ID or project name
api-version	query	TRUE	string	Version of the API to use. This should be set to '5.1-preview.1' to use this version of the api

Request Body

Name	Type	Description
views	JsonPatchOperation	The view to which the package version will be added

For more information, please refer to the REST API documentation as it gets updated.

Feedback

We would love to hear from you! You can report a problem or provide an idea and track it through Developer Community and get advice on Stack Overflow.

---

Top of Page