Support for GitHub Copilot Custom Agents in Azure Boards

Azure Boards now supports selecting GitHub Copilot custom agents when creating a pull request from a work item. Custom agents created at the repository or organization level in GitHub automatically appear in Azure DevOps, and your selected agent will generate the code changes and create the pull request in the chosen repository.

Check out the release notes for details.

GitHub Advanced Security for Azure DevOps

• Permissions enforcement in security overview
• Build identity access restricted for Advanced Security APIs
• Stale scan detection in security overview coverage

Boards

• Azure Boards integration with GitHub Copilot now supports custom agents
• Increased maximum limit for connected GitHub repositories

Repos

• Improved Git policy configuration API

Pipelines

• Improved pipeline run debugging

GitHub Advanced Security for Azure DevOps

Permissions enforcement in security overview

Security overview now enforces the Advanced Security: Read alerts permission across all views (Risk and Coverage). Repositories where the current user lacks this permission are no longer visible in security overview results. This change ensures that security overview respects the same access controls as the repository-level alerts experience, preventing unauthorized visibility into which repositories have active findings.

Build identity access restricted for Advanced Security APIs

Advanced Security REST APIs no longer accept build service identities (such as Project Collection Build Service) as callers. This change prevents pipeline-based automation from accessing or modifying security alert data using build service accounts, reducing the risk of unintended alert state changes during CI/CD runs. If you have automation that interacts with Advanced Security APIs using a build identity, update those workflows to use a named user or service principal with the appropriate Advanced Security permissions.

Stale scan detection in security overview coverage

The security overview coverage pane now identifies tools with scans older than 90 days. Tools that haven't produced results in over 90 days display a stale indicator, helping security teams quickly spot repositories where scanning may have stopped running or where pipeline configurations need attention. This visibility makes it easier to maintain comprehensive scan coverage across your organization and catch configuration drift before it creates blind spots.

Boards

Azure Boards integration with GitHub Copilot now supports custom agents

The Azure Boards integration with GitHub Copilot now supports the selection of custom agents. If you’re not already familiar with custom agents, you can learn more about them in the documentation on creating custom agents.

Once you’ve created a custom agent at the repository or organization level, it will automatically be available in Azure DevOps. When you create a pull request from a work item, you’ll see a new agent selection control next to the repository list.

After selecting a custom agent and clicking Create, that agent will be used to generate the code changes and create the pull request in the selected repository.

Increased maximum limit for connected GitHub repositories

We’ve increased the per-connection limit when linking GitHub repositories to an Azure DevOps project. The new maximum limit in the web experience is now 2,000, matching the limit already available through the Update REST API.

Repos

Improved Git policy configuration API

We’ve improved the policy configuration APIs to make it easier and more efficient to retrieve all policies that apply to a specific repository. You can now query policies defined at the repository level as well as policies applied to any branches or refs within that repository, without needing to scan the entire project. This enhancement reduces unnecessary API calls and improves performance for services that manage policies at scale. Existing policy behavior remains unchanged.

Policy Configurations - Get - REST API (Azure DevOps Git) | Microsoft Learn

Pipelines

Improved pipeline run debugging

In this sprint, we are improving your ability to debug pipeline runs.

It may happen that you need to cancel your run, but the job or stage continue to run, and you are confused. We've added warning messages to let you know when and why this is the case.

Imagine you have the following YAML:

stages:
- stage: WUS1
  jobs:
  - job: DeployWUS1
    condition: eq(variables['Build.SourceBranchName'], 'main')
    steps:
    - task: CmdLine@2
      inputs:
        script: echo "Deploying $(System.StageName)"
    - task: CmdLine@2
      inputs:
        script: sleep 60
- stage: WUS2
  condition: eq(variables['Build.SourceBranchName'], 'main')
  jobs:
  - job: DeployWUS2
    steps:
    - task: CmdLine@2
      inputs:
        script: echo "Deploying $(System.StageName)"

Now, imagine you cancel the run when running job DeployWUS1. The job will continue to run, and so will stage WUS2. Azure Pipelines tells you why the job and the stage continue running.

Another improvement we're bringing is letting you know why a stage is skipped.

Imagine you run the same YAML from a different branch, say, release_123, and you choose to only run stage WUS2. Previously, both WUS1 and WUS2 stages had the same status, Skipped, but it wasn't clear why each of the stages were skipped. Now, you know if the stage was skipped because you deselected it at queue run time or because of its runtime conditions.

Next steps

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.