Support for subpages table in wiki

You can now add subpages table to your wiki pages so you can see the content and links. In Boards, you can now add colors to swimlane and lock custom fields from being edited. We also continue our investments in security and added a new PAT scope for managing pipeline authorization and approvals and checks.

Check out the release notes for details.

Azure Boards

Azure Pipelines

Wiki

Azure Boards

Prevent editing of shareable picklists fields

Custom fields are shared across processes. This can create a problem for picklist fields because we allow process admins to add or remove values from the field. When doing so, the changes affect that field on every process using it.

To solve this problem, we have added the ability for the collection admin to "lock" a field from being edited. When the picklist field is locked, the local process admin can not change the values of that picklist. They can only add or remove the field from the process.

Gif to demo editing of shareable picklist fields.

Swimlane colors

In your Kanban board, swimlanes help you visualize the status of work that supports different service level classes. Now, you can add color to swimlanes to make them easier to identify in your board.

Gif to demo adding color to swimlanes.

Note

This feature will only be available with the New Boards Hubs preview.

Azure Pipelines

New PAT Scope for managing pipeline authorization and approvals and checks

To limit damage done by leaking a PAT token, we've added a new PAT scope, named Pipeline Resources. You can use this PAT scope when managing pipeline authorization using a protected resource, such as a service connection, or to manage approvals and checks for that resource.

Pipelines REST API Updates

The following REST API calls support the new PAT scope as follows:

Experience improvements to pipeline permissions

We've improved the experience around managing pipeline permissions to make the permissions system remember if a pipeline had previously used a protected resource, such as a service connection.

In the past, if you checked off "Grant access permission to all pipelines" when you created a protected resource, but then you restricted access to the resource, your pipeline needed a new authorization to use the resource. This behavior was inconsistent with subsequent opening and closing access to the resource, where a new authorization wasn't required. This is now fixed.

Variables as inputs in checks

Approvals and checks are a runtime security mechanism that allows resource owners to control which pipeline runs can use their resource.

Two popular checks are Invoke Azure Function and Invoke REST API. In the past, when configuring them, one could only use predefined system variables or variable groups.

In this sprint, we've added support for pipeline-defined variables. This works when specifying Function key, Headers, Body, and Query parameters for such checks.

Say you have the following YAML pipeline. Notice we define variables FunctionKey, MyHeader, MyBody, and MyQuery, and a runtime-defined variable namedRetryCount.

variables:
  FunctionKey: <<redacted>>
  MyHeader: "FabrikamHeader"
  MyQuery: "FabrikamQuery"
  MyBody: "FabrikamBody"

stages: 
- stage: Build
  jobs:
  - job: SetRC
    steps:
    - script: echo "##vso[task.setvariable variable=RetryCount;isOutput=true]3"
      name: RCValue
- stage: Deploy
  jobs:
  - deployment: 
    environment: Production
    strategy:
      runOnce:
        deploy:
          steps:
          - script: ./deploy.sh

You can configure an Invoke Azure Function check on the Production environment and reference $(FunctionKey), $(MyHeader), $(MyBody), $(MyQuery), and $(Build.SetRC.RCValue.RetryCount), like in the following screenshot.

Invoke Azure Function

The syntax for using runtime-defined variables is StageId.JobId.StepOrTaskName.Variable.

Learn more about the recommended way to use Invoke Azure Function & REST API checks.

Ability to disable masking for short secrets

Azure Pipelines masks secrets in logs. Secrets can be variables marked as secret, variables from variable groups that are linked to Azure Key Vault or elements of a Service Connection marked as secret by the Service Connection provider.

All occurrences of secret value are masked. Masking short secrets e.g. '1', '2', 'Dev' makes it easy to guess their values e.g. in a date: 'Jan 3, 202***'
It's now clear '3' is a secret. In such cases you may prefer not masking the secret altogether. If it's not possible to not mark the value as secret (e.g. the value is taken from Key Vault), you can set the AZP_IGNORE_SECRETS_SHORTER_THAN knob to a value of up to 4.

Script to self-validate pipeline agent version

We currently have two versions of the Pipeline agent: v2 uses .NET 3.1 Core and v3 uses .NET 6. We're slowly rolling out the v3 agent to supported operating systems, after which we'll retire the v2 agent. For more information, see the upgrade of .NET agent for Azure Pipelines blog post.

We have created a script to help you verify if your self-hosted agents will be able to upgrade. This script will process all pools in your organization and identify v2 agents on operating systems that are not supported by the v3 agent, e.g. CentOS 6, Fedora versions before 31, macOS 10.14, RHEL 6.

Note

Recent builds of the v2 agent will not try to auto-upgrade to the v3 agent on an operating system known not to be compatible with it.

Pipeline run status overview icon

In this sprint, we're making it easier to know the overall status of a pipeline run.

For YAML pipelines that have many stages, it used to be hard to know the status of a pipeline run, that is, is it still running or it finished. And if it finished, what is the overall state: successful, failed, or canceled. We fixed this issue by adding a run status overview icon.

Pipeline run status overview icon

Wiki

Support for subpages table

You can now add a table of content for subpages to your wiki pages. This table will have links to all subpages located under the page where the table of subpages is shown.

You can add the table of subpages either by inserting the special tag [[_TOSP_]] manually or from More options as shown in the animated image below. Only the first [[_TOSP_]] tag is used to create the table of sub pages.

This feature was prioritized based on the following community suggestion tickets:

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,

Rajesh Ramamurthy