Edit

Enhanced YAML preview API & configure upstream source for universal Packages

  • Article

In this sprint, we're rolling out a new API endpoint that allows you to retrieve the finalized YAML body. We're also excited to announce that we're adding the ability to configure your upstream source for universal packages with this release.

Check out the Features list below for details.

Features

Azure Boards

Azure Pipelines

Azure Artifacts

Azure Boards

System work item types on backlogs and boards

We started a private preview of a feature that allows you to add a system work item type to the backlog level of choice. Historically these work item types have only been available from queries.

Process Work Item Type
Agile Issue
Scrum Impediment
CMMI Change Request
Issue
Review
Risk

We are happy to announce that the feature is now out of preview and generally available to all organizations. Adding a system work item type to a backlog level is simple. Just go into your custom process and click the Backlog Levels tab. Select your backlog level of choice (example: Requirements Backlog) and choose the edit option. Then add the work item type.

backlogs

Audit logging event

We have added a new event to the audit logs to help customers better track process related changes. An event will be logged whenever the values on a picklist are changed. Changes to picklist fields are usually the most common changes made to a process. With this new event, organization admins can better track when and who made changes to those fields.

audit-logs

Azure Boards GitHub app repo limit raised (private preview)

If you are using the Azure Boards application from the GitHub marketplace, there is a limit of 100 GitHub repositories you can connect to.  This becomes a blocker for large organizations that can have well over 100 repositories. In this sprint, we changed how Azure Boards connects to your GitHub repos to support well over 100. If you are currently hitting the 100 repo limit, let us know, and we can enable the feature to increase that limit and unblock you. Please email us directly with your organization name (dev.azure.com/{organization}).

Customize work item state when pull request is merged (private preview)

Not all workflows are the same. Some customers want to close out their related work items when a Pull Request is completed. Others want to set the work items to another state to be validated before closing. We should allow for both.

Starting in sprint 174, we have a new feature that allows you to set the work items to the desired state when the pull request is merged and completed. To do this, we scan the pull request description and look for the state value followed by the #mention of the work item(s). In this example, we are setting two user stories to Resolved and closing two tasks.

work-item-state

This feature has been a long time coming and we are excited to see what you think. To start, we are just scanning the pull request description and not including any user interface changes. We wanted to get your feedback first before investing further.

If you are interested in participating in the private preview please email us directly. Don't forget to include your organization (dev.azure.com/{organization}).

Azure Pipelines

Pipelines images announcements

Note

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, Linux and macOS images, please read the following announcements:

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

Agent log uploads improved

When an agent stops communicating with the Azure Pipelines server, the job it was running becomes abandoned. If you happened to be looking at the streaming console logs, you might have gotten some clues about what the agent was up to right before it stopped responding. But if you weren't, or if you refreshed the page, those console logs were gone. With this release, if the agent stops responding before it sends up its full logs, we'll keep the console logs as the next-best thing. Console logs are limited to 1000 characters per line and can occasionally be incomplete, but they're a lot more helpful than showing nothing! Examining these logs may help you troubleshoot your own pipelines, and it will certainly help our support engineers when they assist with troubleshooting.

Optionally mount container volumes read-only

When you run a container job in Azure Pipelines, several volumes containing the workspace, tasks, and other materials are mapped as volumes. These volumes default to read/write access. For increased security, you can mount the volumes read-only by altering your container specification in YAML. Each key under mountReadOnly can be set to true for read-only (the default is false).

resources:
  containers:
    - container: example
      image: ubuntu:18.04
      mountReadOnly:
        externals: true
        tasks: true
        tools: true
        work: false

Fine-grained control over container start/stop

In general, we recommend that you allow Azure Pipelines to manage the lifecycle of your job and service containers. However, in some uncommon scenarios, you may want to start and stop them yourself. With this release, we've built that capability into the Docker task.

Here's an example pipeline using the new capability:

resources:
  containers:
    - container: builder
      image: ubuntu:18.04
steps:
  - script: echo "I can run inside the container (it starts by default)"
    target:
      container: builder
  - task: Docker@2
    inputs:
      command: stop
      container: builder
# if any step tried to run in the container here, it would fail

Also, we include the list of containers in a pipeline variable, Agent.ContainerMapping. You can use this if you want to inspect the list of containers in a script, for example. It contains a stringified JSON object mapping the resource name ("builder" from the example above) to the container ID the agent manages.

Unzip task bundles for each step

When the agent runs a job, it first downloads all the task bundles required by the job's steps. Normally, for performance, it unzips the tasks once per job even if the task is used in multiple steps. If you have concerns about untrusted code altering the unzipped contents, you can trade away a little bit of performance by having the agent unzip the task on each usage. To enable this mode, pass --alwaysextracttask when configuring the agent.

Improve release security by restricting scope of access tokens

Building upon our initiative to enhance security settings for Azure Pipelines, we now support restricting scope of access tokens for releases.

Every job that runs in releases gets an access token. The access token is used by the tasks and by your scripts to call back into Azure DevOps. For example, we use the access token to get source code, download artifacts, upload logs, test results, or to make REST calls into Azure DevOps. A new access token is generated for each job, and it expires once the job completes.

With this update, we build upon improve pipeline security by restricting the scope of access tokens and extend the same to classic releases.

This feature will be on by default for new projects and organizations. For existing organizations, you must enable it in Organization Settings > Pipelines > Settings. > Limit job authorization scope to current project for release pipelines. Learn more here.

YAML preview API enhancements

A few sprints ago, we introduced the ability to preview the complete YAML of a pipeline without running it. With this update, we've created a dedicated new URL for the preview capability. Now you can POST to https://dev.azure.com/{org}/{project}/_apis/pipelines/{pipelineId}/preview to retrieve the finalized YAML body. This new API takes the same parameters as queuing a run, but no longer requires the "Queue builds" permission.

Azure Artifacts

Configure upstream sources for Universal Packages

Now you can configure your Azure Artifacts feeds to automatically download Universal Packages from upstream sources on demand.

Previously, you could configure upstream sources on your feed for NuGet, Python, Maven, and npm packages, but not for Universal Packages. This was due to a difference in the storage technology used for Universal Packages, which support much larger packages than other supported package types.

You can now configure upstream sources for Universal Packages in the same way as for other package types; open your feed settings, click Upstream sources -> Add upstream source -> and choose the source type that is right for you. You will see Universal Packages (UPack) as a new option in the next view (see image below). For more information, please see the upstream sources configuration documentation.

upack

Note that Universal Packages in upstream sources are only supported between feeds in the same DevOps Organization.

Update Package Version REST API now available for Maven packages

You can now use the Azure Artifacts "Update Package Version" REST API to update Maven package versions. Previously, you could use the REST API to update package versions for NuGet, Maven, npm, and Universal Packages, but not Maven packages.

To update Maven packages, use the HTTP PATCH command as follows.

PATCH https://pkgs.dev.azure.com/{organization}/{project?}/\_apis/packaging/feeds/{feedId}/maven/groups/{groupId}/artifacts/{artifactId}/versions/{packageVersion}?api-version=5.1-preview.1

You can set the following:

URI Parameters

Name In Required Type Description
artifactId path TRUE string Artifact ID of the package
feed path TRUE string Name or ID of the feed
groupId path TRUE string Group ID of the package
organization path TRUE string The name of the Azure DevOps organization
version path TRUE string Version of the package
project path string Project ID or project name
api-version query TRUE string Version of the API to use. This should be set to '5.1-preview.1' to use this version of the api

Request Body

Name Type Description
views JsonPatchOperation The view to which the package version will be added

For more information, please refer to the REST API documentation as it gets updated.

Next steps

Note

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

Head over to Azure DevOps and take a look.

Go to Azure DevOps

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