Azure Artifacts simplifies integration with other services

With this update, we have made it easier to authenticate Azure Artifacts with other popular package managers. Find further details about the actual implementation below.

Features

Azure Boards

• Add "Parent Work Item" filter to the task board and sprint backlog
• Improve error handling experience –– required fields on Bug/Task

Azure Pipelines

• Preview of scale set agents
• Ubuntu 20.04 in preview for Azure Pipelines hosted pools
• Support for GitHub packages in YAML pipelines

Azure Artifacts

• Notifications for disabled upstream sources
• License expressions and embedded licenses
• Lightweight authentication tasks

Azure Boards

Add "Parent Work Item" filter to the task board and sprint backlog

We added a new filter to both the Sprint board and the Sprint backlog. This allows you to filter requirements level backlog items (first column on the left) by their parent. For example, in the screenshot below, we have filtered the view to only show user stories where the parent is "My big feature".

Improve error handling experience –– required fields on Bug/Task

Historically, from the Kanban board, if you moved a work item from one column to another where the state change triggered field rules, the card would just show a red error message which will force you to open up the work item to understand the root cause. In sprint 170, we improved the experience so you can now click on the red error message to see the details of the error without having to open up the work item itself.

Azure Pipelines

Preview of scale set agents

We are previewing a new feature called scale set agents which pairs the convenience and elastic capacity of the Microsoft-hosted agents with the control and flexibility of self-hosted agents. With this preview, we now enable you to manage agents to your specification, completely automated, in your Azure subscription. You may want to consider using scale set agents instead of Microsoft-hosted or self-hosted agents when you:

• need more memory, more processor, more storage, or more I/O than what we offer in native Microsoft-hosted agents
• do not want to allow list a large number of IP addresses within your corporate firewall to enable Microsoft-hosted agents to communicate with your servers
• need more Microsoft-hosted agents than we can provide to meet your large scale needs
• need the ability to partition Microsoft-hosted parallel jobs to individual projects or teams in your organization
• do not want to run dedicated agents around the clock but instead want to de-provision agent machines that are not being actively utilized

To use scale set agents, you will first create a VM scale set in your Azure subscription, and then create an agent pool in Azure Pipelines to point to that scale set. Azure Pipelines will automatically scale this pool based on the number of pending jobs and the number of idle machines that you wish to maintain at all times. Azure Pipelines will also install the agent for you on these virtual machines. For more information, see scale set agents. As you preview the feature, please include your feedback on the documentation page.

Ubuntu 20.04 in preview for Azure Pipelines hosted pools

The Ubuntu 20.04 image is now available in preview for Azure Pipelines hosted pools. To use this image, update your YAML file to include vmImage: 'ubuntu-20.04' . Please note, the ubuntu-latest image label will continue to point to ubuntu-18.04 until ubuntu-20.04 comes out of preview later this year.

Please note, since the ubuntu 20.04 image is in preview, it currently doesn't support all of the tooling available in ubuntu-18.04 . Learn more

Support for GitHub packages in YAML pipelines

We have recently introduced a new resource type called packages that adds support to consume NuGet and npm packages from GitHub as a resource in YAML pipelines. As part of this resource, you can now specify the package type (NuGet or npm) that you want to consume from GitHub. You can also enable automated pipeline triggers upon the release of a new package version. Today the support is only available for consuming packages from GitHub, but moving forward, we plan to extend the support to consume packages from other package repositories such as NuGet, npm, AzureArtifacts and many more. Refer to the example below for details:

resources:
  packages:
    - package: myPackageAlias # alias for the package resource
      type: Npm # type of the package NuGet/npm
      connection: GitHubConn # GitHub service connection of type PAT
      name: nugetTest/nodeapp # <Repository>/<Name of the package>
      version: 1.0.9 # Version of the package to consume; Optional; Defaults to latest
      trigger: true # To enable automated triggers (true/false); Optional; Defaults to no triggers

Note: Today GitHub packages only supports PAT based authentication, which means that the GitHub service connection in the package resource should be of type PAT. Once this limitation is lifted, we will provide support for other types of authentication.

By default, packages are not automatically downloaded in your jobs, hence why we have introduced a getPackage macro that allows you consume the package that is defined in the resource. Refer to the example below for details:

- job: job1
  pool: default
  steps:
    - getPackage: myPackageAlias # Alias of the package resource

Azure Artifacts

Notifications for disabled upstream sources

The Azure Artifacts web interface now notifies you when one or more of your feed’s upstream sources isn't functioning. Upstream sources enable you to point a feed (Feed A) to another feed (Feed B), and allow consumers of Feed A to access packages from Feed B without needing to connect directly to it. For more information about upstream sources, please see the Azure Artifacts documentation. Upstream sources may not function if they're disabled at the source, for example if Feed B is silently deleted, customers won't be able to fetch packages from it through Feed A. In the past, this situation could happen without warning, and lead to difficult-to-diagnose operational problems such as sudden build breaks due to missing dependencies (i.e. packages sourced from Feed B in the example above). Now, Azure Artifacts will provide a warning to you when there are problems with any upstream sources of your feeds. When a problem exists, you'll see a banner (red arrow below) in the Azure Artifacts feed detail page.

Clicking on the link in the banner will open a page which shows the status of each upstream source your feed. In addition to information about each upstream source for the current feed, you can see the current status under the "Last synced" column. Upstream sources that are working properly will show a green checkmark with the last time the source's health was verified. Upstream sources that are broken will show a red X along with the time it was checked. Upstream sources that are pending verification will show a blue information icon.

When you click on the last sync time for a broken upstream source, a dialog will open sharing more details about the root cause of the problem (if available). For example, in the picture below, the upstream source in question isn't functioning because the target feed was deleted. The dialog also contains a link to the audit log, to help you understand who has made relevant changes recently. Links to the permissions settings and the Azure Artifacts documentation can also be used to help investigate the root cause.

License expressions and embedded licenses

Now you can see the details of license information for NuGet packages stored in Azure Artifacts while browsing packages in Visual Studio. This applies to licenses which are represented using license expressions or embedded licenses. Now you can see a link to the license information in the Visual Studio package details page (red arrow in the image below).

Clicking on the link will take you to a web page where you can view the details of the license. This experience is the same for both license expressions and embedded licenses, so you can see license details for packages stored in Azure Artifacts in one place (for packages which specify license information and are supported by Visual Studio).

Lightweight authentication tasks

You can now authenticate with popular package managers from Azure Pipelines using light-weight authentication tasks. This includes NuGet, npm, PIP, Twine, and Maven. Previously, you could authenticate with these package managers using tasks which provided a large amount of functionality, including the ability to publish and download packages. However, this required using these tasks for all activities which interacted with the package managers. If you had your own scripts to run for performing tasks like publishing or downloading packages, you wouldn't be able to use them in your Pipeline. Now, you can use scripts of your own design in your pipeline YAML and perform authentication with these new lightweight tasks. An example using npm:

The use of the "ci" and "publish" command in this illustration are arbitrary, you could use any commands supported by Azure Pipelines YAML. This enables you to have complete control of command invocation and makes it easy to use shared scripts in your pipeline configuration. For more information, please see the NuGet, npm, PIP, Twine, and Maven authentication task documentation.

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,

Aaron Hallberg