The yaml below creates a pipeline. The pipeline functions as expected, except when you attempt to view/skip stages via the Portal. At this point, I get the error message Unable to load the pipeline's stages.
When I create a pipeline manually via the Portal, using the same ymlPath as the automatically generated pipeline, I am able to load the pipelines stages.
parameters:
- name: 'branch'
type: string
default: 'main'
- name: 'folderPath'
type: string
- name: 'pipelineName'
type: string
- name: 'repositoryName'
type: string
- name: 'repositoryType'
type: string
default: 'tfsgit'
- name: 'skipFirstRun'
type: boolean
default: true
- name: 'ymlPath'
type: string
- name: 'jobName'
type: string
default: 'CreatePipeline'
- name: 'dependsOn'
type: object
default: []
- name: 'displayName'
type: string
default: 'Create a Pipeline'
jobs:
- job: '${{ parameters.jobName }}'
displayName: '${{ parameters.displayName }}'
dependsOn: '${{ parameters.dependsOn }}'
pool:
vmImage: windows-latest
steps:
- script: echo $(System.AccessToken) | az devops login
displayName: 'Login to DevOps'
- task: PowerShell@2
name: 'CreatePipeline'
displayName: 'Create a Pipeline'
inputs:
targetType: 'inline'
failOnStderr: true
script: |
$pipelineResult = (az pipelines create `
--name "${{ parameters.pipelineName }}" `
--repository "${{ parameters.repositoryName }}" `
--folder-path "${{ parameters.folderPath }}" `
--repository-type "${{parameters.repositoryType }}" `
--branch "${{ parameters.branch }}" `
--skip-first-run "${{ parameters.skipFirstrun }}" `
--yml-path "${{ parameters.ymlPath}}" `
--debug `
| ConvertFrom-Json)
Write-Host "##vso[task.setvariable variable=pipelineId;isOutput=true;]$($pipelineResult.id)"
env:
SYSTEM_ACCESSTOKEN: $(System.AccessToken)
az pipeline show
CLI command directly but face policy issues due to my organisation blocking it.My organization recently saw the same issue: we couldn't load our pipeline stages or resources, despite our YAML syntax being fine. I'm not sure if our solution will suit yours, but we found that an empty "Default agent pool for YAML" setting was causing it (seems like a Microsoft bug). To find this setting do the following:
I don't believe the value particularly matters. We specify the pool for all our pipeline jobs, so it never gets used. I hope that helps you as it helped us!