Improved GitHub builds and suggested work item paths – VSTS Sprint 129 Update

Since we skipped the deployment of an update over the recent holidays, we now return with features from both Sprint 128 and 129. In the Sprint 129 Update of Visual Studio Team Services (VSTS), you’ll notice several enhancements that should delight those from across your team. Most notably, we strengthen our integration with GitHub by enabling you to build pull requests from repository forks on and continuously integrate from GitHub Enterprise through an official build source.

Other feature highlights include:

What’s new in VSTS

Dashboards and Analytics

View Analytics Widgets as a Stakeholder

Installing the Analytics extension adds 6 powerful widgets to your widget catalog: Cumulative Flow Diagram, Lead Time, Cycle Time, Velocity, Burndown, and Burnup. Now, those with the free Stakeholder license can view all the Analytics widgets too!

To use the Analytics OData endpoint or Power BI to connect to Analytics, a Basic license is still required.

Integrate Power BI with VSTS Analytics using new views

The default views in the VSTS Power BI Desktop Connector help you get started on working with VSTS data right away. We’ve added additional views with common historical definitions to allow you to more easily perform trending and bug analysis. Refer to our guidance on connecting to VSTS with Power BI Data Connector for more information.

New default views

In the upcoming February release of Power BI Desktop, we will introduce the ability to create your own views, which will make working with the specific data you need in Power BI even easier.


View pull request merge commit

Pull request diff views are great at highlighting the changes introduced in the source branch. However, changes to the target branch may cause the diff view to look different than expected. A new command is now available to view the diff of the “preview” merge commit for the pull request - View merge commit. This merge commit is created to check for merge conflicts and to use with a pull request build, and it reflects what the merge commit will look like when the pull request is eventually completed. When the target branch has changes not reflected in the diff, the merge commit diff can be useful for seeing the latest changes in both the source and target branches.

View pull request merge commit

Another command that’s useful in conjunction with the View merge commit command is Restart merge (available on the same command menu). If the target branch has changed since the pull request was initially created, running this command will create a new preview merge commit, updating the merge commit diff view.

Help reviewers using pull request labels

Sometimes it’s important to communicate extra information about a pull request to the reviewers. Maybe the pull request is still a work in progress, or it’s a hotfix for an upcoming release - so you append some extra text in the title, perhaps a “[WIP]” prefix or “DO NOT MERGE”. Labels now provide a way to tag pull requests with extra information that can be used to communicate important details and help organize pull requests.

PR request labels

In a future release, we’ll make labels even more useful by making it easier to filter pull requests using labels.

View remaining policy criteria for pull request auto-complete

Auto-complete is a useful feature for teams using branch policies, but when using optional policies, it can be unclear exactly what is blocking a pull request from being completed. Now, when setting auto-complete for a pull request, the exact list of policy criteria that are holding up completion are clearly listed in the callout box. As each requirement is met, items are removed from the list until there are no remaining requirements and the pull request is merged.

PR auto-complete lists

Discuss math in pull requests

Need to include an equation or mathematical expression in your pull request comments? You can now include TeX functions in your comments, using both inline and block commenting. See the list of supported functions for more information.

PR markdown comment with math

Control who can contribute to pull requests

Previously, anyone who could view a Git repository could work with its pull requests. We’ve added a new permission called Contribute to pull requests that controls access to creating and commenting on pull requests. All users and groups that previously held the Read permission will also be granted this new permission by default. The introduction of this new permission gives administrators additional flexibility and control. If you require your Readers group to be truly read-only, you can deny the Contribute to pull requests permission.

See the quickstart documentation for setting repository permissions for more information.

Integrate using the pull request status API and branch policy

Branch policies enable teams to maintain high quality branches and follow best practices during the pull request workflow. Now, you can use the pull request status API and branch policy to integrate custom tooling into pull request workflows. Whether it’s integrating with a 3rd party CI/CD solution, or enforcing your own internal process requirements, the status API can help. Check out our code, samples, and documentation for more information.


Move work using suggested Areas and Iterations

It can be common to work in the same area or iteration and repeatedly browse through the hierarchies when moving work items around. The Area and Iteration path controls now include a list of recently used values as Suggestions, giving you quick access to set and move on.

Area drop down list

In addition, Iteration dates are included to the right of the name so that you can quickly judge when a work item should be delivered.

Iteration drop down list

Build and Release

Build GitHub pull requests from repository forks

GitHub pull requests from repository forks can now be automatically built by VSTS. This ensures that changes successfully build and tests pass before they are merged. By default, secrets associated with your build definition are unavailable to builds of pull requests from forks. See the security considerations documentation for more information.

Configuration for pull request validation of public fork PR builds

Build with continuous integration from GitHub Enterprise

You now have better integration with VSTS for performing continuous integration (CI) builds if you use GitHub Enterprise for version control. Previously, you were limited to polling for code changes using the External Git connector, which may have increased the load on your servers and caused delays before builds were triggered. Now, with official GitHub Enterprise support in VSTS, team CI builds are immediately triggered. In addition, the connection can be configured using various authentication methods, such as LDAP or built-in accounts.

GitHub Enterprise build source option

Build with the appropriate agent by default

When you use one of our templates to create a new build definition, we now select a hosted agent queue for you by default. For example, the Ant and Maven templates default to the Hosted Linux queue. Xcode and Xamarin.iOS templates default to Hosted macOS Preview. The ASP.NET Core template defaults to Hosted VS2017. Of course, you can still change the queue to your preference, but this default saves some time when defining a new build process and otherwise avoids having to re-set the appropriate agent queue.

Default hosted agent option in Build


Screenshot desktop apps through the Chrome browser

The Test & Feedback extension now has support for capturing screenshots of desktop applications through the Chrome browser. With the browser extension installed, select the application you are testing, take screenshots, annotate, and create bugs or tasks.

Application button in Test & Feedback

Filter large test results by Test Name

Over time, test assets accrue. For large applications, they can easily grow to tens of thousands of tests. In our earlier sprint we added two new filters under Tests tab in Build and Release - Container (DLLs) and Owner (Container Owner). To enrich this experience further, we have added a new filter based on Test Name, which allows you to quickly search for the test you are interested in. The various filters continue to be cumulative.

Filter test by test name

Run Functional Tests and Deploy Test Agent tasks are now deprecated

Last year, we started on the journey to unify agents across build, release, and test. This was intended to address various pain points associated with using WinRM based Deploy Test Agent and Run Functional Tests tasks. It also enables you to use the Visual Studio Test (VSTest) task for all your testing needs, including:

  • Unit tests
  • Functional (UI/non-UI) tests
  • MSTest based tests
  • 3rd party framework-based tests
  • Assembly-based test specification or running tests with Test Plan/Test Suite
  • Single agent test execution as well as distributing tests over multiple agents

The unified agents approach also allows admins to manage all machines being used for CI/CD in a uniform manner.

Visual Studio Test task

Over the course of the last several sprints, we delivered several crucial pieces to enable this capability, including:

With all the above now in place, we are ready to deprecate these two tasks. While existing definitions that use the deprecated tasks will continue to work, we encourage you to move to using VSTest to take advantage of continued enhancement over time.

Delete Test Plans / Test suites

Users can now delete Test Plans / Test suites if they the following permissions

  • Test suite delete: View test runs + Delete test runs + Manage test suites
  • Test plan delete: View test runs + Delete test runs + Manage plan suites


Wiki Search now Generally Available

After a public preview of Wiki search in December, we are now making it generally available. You can search for your favorite wiki pages by title or content right alongside code and work items.

Wiki can be used for a variety of content. Sometimes it can be useful to print content from Wiki to read in your spare time, add comments using pen and paper, or even share an offline PDF copy with those outside of your VSTS project. Now, simply click on the context menu of a page and select Print page. This feature was prioritized based on a suggestion.

Wiki menu print page option

Currently this feature is not supported on Firefox.

Contribute to Wiki pages with ease using keyboard shortcuts

You can now use shortcuts to perform common edit and view actions in Wiki even faster using only your keyboard.

While viewing a page, you can add, edit, or create a subpage, for example.

Wiki view keyboard shortcuts popup

While editing a page, you can quickly save, save and close, or just close.

Wiki edit keyboard shortcuts popup

These are in addition to standard editing shortcuts such as Ctrl+B for bold, Ctrl+I for italics, Ctrl+K for [linking](#) etc. See the full list of keyboard shortcuts for more information.


Calculate price without leaving the extension page

All paid VSTS extensions and VS subscriptions in the Marketplace now feature a calculator on the Pricing tab. You can now figure out the price corresponding to the selected quantity in your currency, without leaving the extension page.

Marketplace price calculator

Note: The final pricing will be determined based on the Azure subscription used for a purchase.


Manage permissions directly on Azure AD groups

To avoid extra layers of groups in VSTS, you can now manage permissions directly on Azure Active Directory groups. This bring our support for Azure AD groups on par with VSTS groups.

Azure AD group permissions

See the about permissions and groups documentation for more information.

Connect or disconnect a VSTS account to Azure Active Directory via new Azure portal

With the retirement of the classic Azure portal (, you can now connect or disconnect your VSTS account from Azure Active Directory via the new Azure portal ( using the Connect control on the account blade. See the documentation for connecting to Azure AD for more information.

Connect Azure AD through Azure Portal

Warning for accounts with a single Project Collection Administrator

For Microsoft Account (MSA)-backed VSTS accounts, a warning has been added in the Security tab if we detect that the account has multiple users but is administered by a single Project Collection Administrator. It is recommended to have more than one administrator to avoid the account becoming locked out if the current administrator leaves the company. This message is only a recommendation and will not impact any of your existing settings.

Account warning for single admin

Next steps and Feedback

We would love to hear what you think about these features. Report a problem or provide a suggestion if you have ideas on things you’d like to see us prioritize, through the feedback menu.

Feedback menu

You can also get advice and your questions answered by the community on Stack Overflow.


Jamie Cool