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
- Experience improvements to pipeline permissions
- Ability to disable masking for short secrets
- New PAT Scope for managing pipeline authorization and approvals and checks
- Variables as inputs in checks
- Script to self-validate pipeline agent version
- Pipeline run status overview icon
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.
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.
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.
The following REST API calls support the new PAT scope as follows:
- Update an Approval supports scope
Pipeline Resources Use - Manage Checks supports scope
Pipeline Resources Use and Manage - Update Pipeline Permissions For Resources supports scope
Pipeline Resources Use and Manage - Authorize Definition Resources supports scope
Pipeline Resources Use and Manage - Authorize Project Resources supports scope
Pipeline Resources Use and Manage
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.
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.
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.
You can also get advice and your questions answered by the community on Stack Overflow.
Thanks,
Rajesh Ramamurthy