Enhanced AB# link tracking in GitHub pull requests
With this update, AB# links now appear directly in the Development section of GitHub pull requests, as long as they are included in the pull request description. This enhancement simplifies access to linked work items through the Azure Boards and GitHub integration.
We’re also excited to introduce enhanced monitoring tools, offering greater visibility into your repository’s health and helping you maintain its performance more efficiently!
Check out the release notes for details.
GitHub Advanced Security for Azure DevOps
- Pull request branches now visible in Advanced Security branch picker
- Automatic updates for default branch changes in Advanced Security
- Generic third-party SARIF support for Advanced Security
- Alert rule IDs now integrated into result fingerprints
- Expanded set of Secret Scanning detections
Azure Boards:
- AB# links on GitHub pull requests
- REST API support for connecting GitHub repositories
- Permanently delete attachments
Azure Repos
Azure Pipelines
Azure Test Plans:
- Seamless build Pipeline integration for test case execution
- Test and feedback extension in Manifest V3 (Edge release)
GitHub Advanced Security for Azure DevOps
Pull request branches now visible in Advanced Security branch picker
Pull request branches were previously hidden in the branch picker, even though scanning on pull request branches was possible. Now, these branches are visible in the Advanced Security branch picker and can be searched.
Automatic updates for default branch changes in Advanced Security
In the past, the Advanced Security repository tab did not automatically update when the default branch changed, requiring manual selection of the new branch in the branch picker. Now, the tab automatically detects and displays alerts for the newly designated default branch upon visiting the page.
Additionally, the Security Overview updates to reflect default branch changes, although there may be a slight delay before the updated alert results are processed.
Generic third-party SARIF support for Advanced Security
You can now upload results from your third-party scanning tool to show in the Advanced Security code scanning tab.
Using a scanning tool that publishes a SARIF file to the $(Agent.TempDirectory)/.advsec
directory, conforms to the SARIF 2.1 standard, and runs the AdvancedSecurity-Publish@1 after the task will upload results to the code scanning tab.
Note
The file path associated with a result in the SARIF file must be accessible to the AdvancedSecurity-Publish@1
task running in the build agent.
Alert rule IDs now integrated into result fingerprints
Previously, third-party tool results with the same fingerprint, hash, tool, and rule name were grouped into one alert, even if they had different rule IDs.
With this update, rule IDs are now included in the fingerprint, creating separate alerts for results with different rule IDs, even if other data points are the same. Existing alerts will be updated and split accordingly.
Expanded set of Secret Scanning detections
We're expanding the set of partner patterns that can be detected with Secret Scanning. This expansion brings in several high confidence patterns for new token types.
For more information on the types of partner patterns that GitHub Advanced Security Secret Scanning detects, see Secret scanning alerts for GitHub Advanced Security for Azure DevOps.
Azure Boards
AB# links on GitHub pull requests
As part of our ongoing enhancements to the Azure Boards + GitHub integration, we’re excited to introduce a new feature that streamlines how AB# links are displayed. With this update, AB# links now appear directly in the Development section of GitHub pull requests, making it easier to access linked work items without searching through descriptions or comments.
These links will only appear when AB# is included in the pull request description. If you link directly from a work item, they won’t be displayed in the Development section. Additionally, removing the AB# link from the description removes it from the Development control.
REST API support for connecting GitHub repositories
We're introducing new REST API endpoints that enable you to automate the addition and removal of GitHub repositories in your Azure DevOps Projects. Additionally, we increased the repository limit per connection from 500 to 2,000 when using these endpoints.
These endpoints include:
We have also provided sample code to help you get started.
Permanently delete attachments
In some cases, simply removing an attachment from a work item may not fully resolve security risks, especially if the file is flagged as malicious. Shared links to the attachment could still be accessible across other work items, comments, or external channels. To address this, we added a feature that allows users with "Permanently delete work items" permissions to permanently remove attachments.
This action can be performed from the Attachments tab on the work item form, under a new section called "Deleted Attachments". This section is visible only to users with the necessary permissions to permanently delete work items.
Once an attachment is permanently deleted, all associated links return a "File attachment does not exist" error.
Note
This feature is only available in the New Boards Hub.
Azure Repos
New "Health and usage" panel in repo file hub
As Git repositories grow, they accumulate commits, blobs, and other data, which can increase the load on Azure DevOps infrastructure, impacting performance and user experience. Maintaining a healthy repository is key to ensuring consistent performance and reliability.
To support this, we now monitor several factors like repository size, commit frequency, contents, and structure. If your repository begins to strain the infrastructure, you may receive a notification with recommendations for corrective action. By managing your repository’s health, you can prevent disruptions and ensure smooth operations.
To check your repository’s health, go to Azure Repos, > Files and choose “Health and usage” from the ellipsis menu to access the Repository health and usage panel.
Azure Pipelines
Azure Pipeline agent v4 runs on .NET 8
The Azure Pipeline agent v3 currently uses .NET 6, but with the end-of-life for .NET 6 approaching, we're upgrading the agent to .NET 8. This update will be rolled out over the coming weeks.
If you're using self-hosted agents on an operating system that isn't supported by .NET 8, your agent won’t be upgraded to v4. Instead, pipelines running on unsupported operating systems display warnings in the pipeline logs. You can use the QueryAgentPoolsForCompatibleOS.ps1 script to identify any pipeline agents running on outdated operating systems proactively.
The following operating system versions won't be supported by the updated v4 agent:
- Alpine Linux 3.13 - 3.16
- Debian 10
- Fedora 36 - 38
- macOS 10 & 11
- openSUSE 15.0 - 15.4
- Oracle Linux 7
- Red Hat Enterprise Linux 7
- SUSE Enterprise Linux 12
- Ubuntu, 16.04, 18.04
- Windows 7, 8 & 10 up to 21H2
Preview mode for shell tasks arguments validation
Shell tasks such as Bash@3, BatchScript@1, CmdLine@2 and PowerShell@2 can be protected from command injection by enabling shell tasks arguments validation in organization or project settings.
Enabling shell tasks arguments validation can break existing scripts as input is rejected by input validation. For example, some characters are considered a command separator and rejected when this setting is enabled.
To make this transition smoother, we added a preview mode. With preview mode enabled, you receive warnings in your pipeline and audit logs, giving you visibility into potential issues without interrupting your tasks or workflows.
Go to Organization Settings > Pipelines > Settings > Task restrictions > Audit On:
Azure Test Plans
Seamless build Pipeline integration for test case execution
We’ve simplified the test case execution process by seamlessly integrating build pipeline configurations. Build definitions and IDs set at the test plan level now automatically propagate to the Web Runner, eliminating the need for manual configuration each time. This improvement saves time and enhances efficiency, allowing you to focus on more critical tasks.
Test and feedback extension in Manifest V3 (Edge release)
We’ve been gradually releasing this upgrade in Chrome, and now we’re expanding the rollout to Edge.
This update transitions our implementation from Manifest V2 to V3, in line with Google's deprecation schedule for Manifest V2. While the core features of the extension remain unchanged, the update enhances both security and performance.
For more details, check out our recent blog post about this update. Test & Feedback Extension in Manifest V3
Next steps
Note
We are rolling out the feature. Receiving it in your organization depends on various factors, and it may arrive later if you don't have it yet.
Head over to Azure DevOps and take a look.
How to provide feedback
We would love to hear what you think about these features. Use the help menu to report a problem or provide a suggestion.
You can also get advice and your questions answered by the community on Stack Overflow.
Thanks,
Dan Hellem