Org-level setting for default branch

As an addition to the default repository branch setting, we have now added a default branch name for the org-level so that projects default to the organization setting when the branch name isn't specified.

Check out the Features list below for details.

Features

Azure Boards

• Customize work item state when pull request is merged
• Parent field on the task board

Azure Repos

• Org-level setting for default branch
• Add a new auth scope for contributing PR comments

Azure Pipelines

• Configure draft PR validation for GitHub repositories

Azure Boards

Customize work item state when pull request is merged

A few sprints back, we released this feature under private preview. After taking feedback and fixing bugs, it is now generally available in all organizations. 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.

Azure Repos

Org-level setting for default branch

There is now an organization-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.

Azure Pipelines

Configure draft PR validation for GitHub repositories

Customers have varied processes for their pull requests. In some cases, they want to run validation builds on their draft PRs. In others, they do not want draft PRs to consume and waste their parallel jobs.

This feature adds drafts to the pr trigger YAML syntax for GitHub draft pull requests. This feature allows a customer to choose if they would like their draft PRs to queue a build. The default option is true (a build will be queued) like it currently is for GitHub PRs. This change works for both OAuth and GitHubApp connections.

Schema:

pr:
  autoCancel: boolean # indicates whether additional pushes to a PR should cancel in-progress runs for the same PR. Defaults to true
  branches:
    include: [ string ] # branch names which will trigger a build
    exclude: [ string ] # branch names which will not
  paths:
    include: [ string ] # file paths which must match to trigger a build
    exclude: [ string ] # file paths which will not trigger a build
  drafts: boolean # whether to build draft PRs

This feature only applies to PRs in GitHub. There is no change in behavior for Azure Repos, where PR validation is configured through branch policies. Draft PRs in Azure Repos are not validated by Azure Pipelines.

Next steps

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,

Vijay Machiraju