View linked GitHub activity from the Kanban board - Sprint 153 Update
In the Sprint 153 Update of Azure DevOps, we continue to enhance the Azure Boards integration with GitHub. Now you can get information about your linked GitHub commits, pull requests and issues from your Kanban board. This information will give you a quick sense of where an item is and allow you to directly navigate to the GitHub commit, pull request, or issue for more details.
Check out the Features list below for more.
- Changes to Azure DevOps IP address ranges
- Auditing public preview
- Manage security groups and permissions from the command line
- Quickly view linked GitHub activity from the Kanban board
- Copy work items with attachments and links
- Preview text files on work item
- See all teams in boards, backlogs, and sprints pickers
- Updates to hosted pipelines images
- A simpler way to work with artifacts
- Use cron syntax to specify schedules in a YAML file
- Updates to multi-stage pipelines public preview
Changes to Azure DevOps IP address ranges
We are performing a front-end routing migration that will increase availability and decrease latency. As part of this migration, our IP address space will change. If you are currently using firewall rules to allow traffic to Azure DevOps, please be sure to update these rules to account for the new IP ranges.
For more details about this update, see the blog post with the announcement here.
Auditing public preview
We are excited to announce that auditing for Azure DevOps is now available for all organizations as a public preview!
Auditing will log changes that occur throughout an Azure DevOps organization. When an auditable event occurs, a log entry is recorded. Some examples of audit events include: a Git repository is created, permission changes, resource deletion, code download, accessing the auditing feature, and much more.
The audit events will have information such as IP, who caused the event to be logged, what happened, and other useful information that can help you answer who, what, when, and where questions.
Audit events will be stored for 90 days. However, you can back up audit events to an external location via the auditing REST API to keep them for more than 90 days.
By default, only the project collection administrators can access the audit log. An administrator can grant separate permission to team members to access the audit logs. The auditing feature can be found under the Organizations settings. For more information, see our documentation.
Manage security groups and permissions from the command line
You can now manage security groups and permissions from the command line by using the az devops security permission commands. By using the commands, you can create scripts to manage permissions and standardize the process of creating security groups. In addition, you can use the commands to run reports to view a list of security groups and corresponding permissions.
Quickly view linked GitHub activity from the Kanban board
When reviewing the Kanban board yourself or as a team, you often have questions such as "has this item started development yet?" or "is this item in review yet?" With the new GitHub annotations on the Kanban board, now you can get a quick sense of where an item is and directly navigate to the GitHub commit, pull request, or issue for more detail. See the Customize cards documentation for more information about this and the other annotations for Tasks and Tests.
Copy work items with attachments and links
Sometimes you may need to create a copy of a work item and include minor changes to the new work item. Previously, you could only copy the work item’s content and links. Now, you can copy attachments as well.
To copy a work item with attachments, select copy work item from the ellipsis and then select attachments.
Preview text files on work item
Often, .txt and .log files are attached to work items for light notes or documentation of events. You can now preview those text attachments on the work item, so you don't need download them to see their contents.
See all teams in Boards, Backlogs, and Sprints pickers
When navigating between teams, you may want to search for a team that you don't have in your favorites. Previously, you had to navigate to a directory page to search for the team. Now, you can search for any team in the project from the picker on Boards, Backlogs, or Sprints without interrupting your workflow.
Updates to hosted pipelines images
We are not deploying the Sprint 152 Update for the VS2017 and VS2019 images. The Sprint 153 Update will include the Sprint 152 changes.
With this update, we added Windows SDK 18362 to the VS2019 image. In addition, we downgraded several versions of Python to address a bug. The new versions in this update are the following:
A simpler way to work with artifacts
The new YAML keywords and updated tasks are currently in preview.
We added two YAML keywords (publish and download) to make it easier to publish and consume artifact in YAML-based pipelines. These keywords can be used in place of traditional task steps for most scenarios. For example, you can publish (upload) the contents of the bin directory as an artifact named "binaries" use the following YAML code:
steps: - publish: bin artifact: binaries
To consume (download) the artifact in the same job or a later job in the same pipeline use the following:
steps: - download: current artifact: binaries
We have also updated the Download Pipeline Artifact to let you download artifacts that have been published with the traditional Publish Build Artifacts task. Now you don't need to know how an artifact was published when you are going to consume it in your pipeline.
To learn more about these changes, see the pipeline artifacts in Azure Pipeline documentation here.
Use cron syntax to specify schedules in a YAML file
Previously, you could use the UI editor to specify a scheduled trigger for YAML pipelines. With this update, you can schedule builds using cron syntax in your YAML file and take advantage of the following benefits:
- Config as code: You can track the schedules along with your pipeline as part of code.
- Expressive: You have more expressive power in defining schedules than what you were able to with the UI. For instance, it is easier to specify a single schedule that starts a run every hour.
- Industry standard: Many developers and administrators are already familiar with the cron syntax.
schedules: - cron: "0 0 * * *" displayName: Daily midnight build branches: include: - master - releases/* exclude: - releases/ancient/* always: true
Going forward you won't be able to add or update schedules that have been created using the UI editor. We will continue to honor those schedules for some time, but we recommend that you remove them from the UI and add them to the YAML file.
Updates to multi-stage pipelines public preview
We continue to add features to the multi-stage pipelines public preview. With this update we made improvements to the log viewing experience, added the ability to view all runs inside of folders, and supported build extensions in the new pages.
In addition, we fixed a few bugs and added the ability to create new pipelines directly into a folder. In the previous sprint, we completed work around browsing and downloading Artifacts, which was a popular feature request.
Go get command support in Azure Repos
Go is an open source programming language, also referred to as Golang. In Go, you can use the get command to download and install packages and dependencies. With this update, we've added support for
go get within an Azure DevOps repository. With
go get, you will be able to download packages with their dependencies named by the import paths. You can use the
import key word to specify the import path.
Filtered downloads for Universal Packages
Until now, you've always had to download an entire Universal Package, even if you only needed a few files from it. With this update, you can specify a minimatch pattern (using the same syntax as Azure Pipelines) to download a subset of files. For example:
az artifacts universal download --organization "https://dev.azure.com/myorganization/" --feed "myFeed" --name "myPackageName" --version 1.0.0 --path . --file-filter "**/*.exe;**/*.dll"
To use this feature, make sure you've updated to the latest Azure DevOps CLI extension: az extension update -n azure-devops
Introducing organization level package search that provides fast, flexible, and accurate search across all the packages in various feeds of an organization. As the number of packages grow in your organization and are divided across multiple feeds, finding the package that you need becomes increasingly difficult. Package search can quickly and efficiently locate relevant packages across all your organization feeds.
By using package search, you can:
- Search package by title and description: You can quickly and easily find relevant packages by using free text search on title and description. You can also narrow your search by using Boolean operators and combine search criteria.
- Search across all your organization feeds: Search in your and your team's feeds across the organization. Narrow your search by using feed, view, and package type filters. Use wildcards to widen your search and Boolean operators to fine-tune it.
You can learn more about package search here.
Support for queries with tree of work items
Now, you can use queries that group work items into a hierarchy in a wiki page. You can embed queries with a tree of work items in a wiki page to show Epics and Features along with the child Tasks and User Stories.
Top publisher certification program
We have created a Top Publisher program in the Marketplace to help you evaluate or acquire Azure DevOps extensions/integrations with confidence. The Top Publisher badge implies that the publisher has shown commitment to their customers and the Marketplace through exemplary policies, quality, reliability, and support. Marketplace assigns the badge to a publisher after carefully reviewing the publisher across a variety of parameters. Read about them here and check out the offerings from the Top Publishers.
These features will roll out over the next two to three weeks.
Head over to Azure DevOps and take a look.
We would love to hear what you think about these features. Use the feedback menu to report a problem or provide a suggestion.
You can also get advice and your questions answered by the community on Stack Overflow.