Customize your default branch name

In this sprint, we have introduced a new option that allows customers to set a custom default branch name for all new repositories.

Check out the Features list below for more information.

Features

Azure Boards

Azure Repos

Azure Pipelines

Azure Boards

Stakeholders can move work items across board columns (private preview)

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 a private preview this sprint that will enable Stakeholders to move work items across board columns. If you're interested in participating in the private preview, please email us directly with your organization name (example: dev.azure.com/{organization name}).

Azure 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.

 default-branch-name

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.

Azure Pipelines

Pipelines images announcements

Note

We’re constantly working to improve your experience using Azure Pipelines. To learn more about upcoming updates on our Windows/Linux/macOS images updates please check here:

Azure Pipelines images are continuously updated in an effort to provide users with the best experience possible. These routine updates are predominantly aimed at addressing bugs or out of date software. They will often have no impact on your pipelines, however this is not always the case. Your pipeline may be impacted if it takes a dependency on a piece of software that has either been removed or updated on the image.

To learn more about upcoming updates on our Windows and Linux images, please read the following announcements:

To view release notes for upcoming (pre-release) and deployed changes, please subscribe to the following release notes:

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.

Updates to macOS 10.14 (Mojave) image

In the next few weeks, we'll update the Node.js version on the macOS 10.14 (Mojave) image from 6 to 8. If you still need to use node.js version 6, consider using the node.js tool installer task - here.

In addition to these changes, the macOS 10.14 image will be added to the virtual environment repo and begin receiving tooling updates monthly instead of weekly.

GitHub draft pull requests do not trigger pipelines

When you create a draft pull request in Azure Repos, we wouldn't trigger a PR validation pipeline configured in your branch policy. We consider a draft pull request to be just that - a draft for which we shouldn't automatically run validations. While this use case worked for Azure Repos, the same behavior didn't hold for GitHub repos.

With this change, we're making the experience consistent for GitHub repos as well. When you create a draft pull request in GitHub, we won't start a pipeline automatically even if you configure a pull request trigger for the target branch. In order to validate your changes in a draft pull request, you can manually start a pipeline pointing to the ref of the pull request.

Next steps

Note

These features will roll out over the next two to three weeks.

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.

Make a suggestion

You can also get advice and your questions answered by the community on Stack Overflow.

Thanks,

Aaron Hallberg