Troubleshoot YAML Build First Run

DZone 's Guide to

Troubleshoot YAML Build First Run

We take a step-by-step look at how to fix a common error developers face when working with YAML builds.

· Web Dev Zone ·
Free Resource

Scenario: You create a branch in your git repository to start with a new shiny YAML build definition for Azure DevOps, you create a YAML file, push the branch to Azure DevOps, and create a new build based on that YAML definition. Everything seems okay, but when you press the run button you got and error

Could not find a pool with name Default. The pool does not exist or has not been authorized for use. For authorization details, refer to https://aka.ms/yamlauthz.


Figure 1: Error running your new shiny pipeline

Okay, this is frustrating and following the link gives you little clue on what really happened. The problem is that, with the new editor experience, when you navigate to the pipeline page, all you see is the editor of YAML build and nothing more.


Figure 2: New Editor page of YAML pipeline, advanced editor and nothing more.

The new editor is fantastic, but it somewhat hides the standard configuration parameters page, where the default branch can be set. As you can see from Figure 2, you can specify the pool name (default) and trigger it directly in the YAML build, so you'd think that this is everything you'd need, but there is more. Clicking on the three buttons in the right upper corner you can click on the trigger menu to open the old editor.


Figure 3: Clicking on the Triggers menu item will bring on the old UI.

This is where the YAML pipeline experience still needs some love. You are surely puzzled why you need to click the triggers menu item if you already specified triggers directly in the YAML definition, but the reason is simple — it will open the old pipeline editor page.

The new editor page with the YAML editor is fantastic, but you should not forget that there are still some parameters, like a default branch, that are editable from the old interface.

The trigger page is not really useful, it only gives you the ability to override the YAML configuration, but the important aspect is that we can now access the first tab of the YAML configuration to change the default branch.


Figure 4: The trigger page is not useful, but now we can access the default configuration for the pipeline.


Figure 5: Default configuration tab where you can edit default branch

In Figure 5, we can now understand what went wrong. The wizard created my pipeline using master as the default branch, but clearly my buid YAML file does not exists in master, but exists only in my feature branch. Just change the default build to the branch that contains your build definition file, save and queue again; now everything should work again.

This trick also works when you got errors about not being authorized to use endpoints, like sonar endpoint, nuget endpoint, etc.

Happy YAML building experience!

buid files ,web dev ,yaml ,yaml build

Published at DZone with permission of Ricci Gian Maria , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}