Skip to content

fix: add agent pool + queue-id to initialise-project + ADO troubleshooting docs#143

Open
pgabriel-01 wants to merge 1 commit intoAzure:mainfrom
pgabriel-01:fix/ado-pool-and-queue
Open

fix: add agent pool + queue-id to initialise-project + ADO troubleshooting docs#143
pgabriel-01 wants to merge 1 commit intoAzure:mainfrom
pgabriel-01:fix/ado-pool-and-queue

Conversation

@pgabriel-01
Copy link
Copy Markdown
Contributor

PR Summary into Azure/mlops-v2

Checklist

I have:

  • read and followed the contributing guidelines
  • PR has a meaningful title
  • Summarized the changes
  • PR is ready to merge and NOT WORK IN PROGRESS

Changes

Three related fixes for issues users hit when running initialise-project on a freshly-provisioned Azure DevOps organization.

1. initialise-project.yml — missing agent pool

InitialiseProjectJob had no pool: block. ADO falls back to the org's default pool, which on new orgs may be unset, causing the job to fail to schedule. Added explicit:

pool:
  vmImage: ubuntu-latest

2. create_ado_pipelines.sh — missing --queue-id

az pipelines create was called without --queue-id. On newly-provisioned projects this can fail with "Could not queue the build because there were validation errors or warnings" because the default queue-to-pool association is not yet established.

Fix: resolve the queue ID dynamically by pool name before the loops:

agent_pool_name="${AGENT_POOL_NAME:-Azure Pipelines}"
queue_id=$(az pipelines queue list \
    --project "$project_name" \
    --query "[?name=='$agent_pool_name'].id | [0]" \
    -o tsv)

Both az pipelines create calls now pass ${queue_id:+--queue-id $queue_id} (the parameter is omitted gracefully if the lookup fails, preserving backward compatibility). Self-hosted pool users can override via the AGENT_POOL_NAME environment variable.

3. deployguide_ado.md — Troubleshooting section

Added a new Troubleshooting section before Next Steps in MLOps, covering the five most common failure modes reported by users:

  1. No hosted parallelism granted — link to https://aka.ms/azpipelines-parallelism-request.
  2. Missing "Create build pipeline" permission — Project Settings → Permissions.
  3. Stale folders/repo on retry — clean-up checklist before re-running initialise-project.
  4. Retired ubuntu-20.04 image — pointer to fix in mlops-project-template.
  5. Queue association failure on new projects — covered by the script change above.

Testing

  • bash -n .azuredevops/scripts/create_ado_pipelines.sh — syntax OK.
  • ${queue_id:+--queue-id $queue_id} expansion verified to expand only when set.
  • Markdown rendering verified.

Merge note

Requesting squash and merge.

Reported by Vicky Arpatzoglou via accelerator feedback (initialise-project failures, parallelism, build-pipeline permissions, stale folders, ubuntu-20.04 image).

fixes #

…nes create

The InitialiseProjectJob in initialise-project.yml had no pool block,
causing the job to fail to schedule on freshly-provisioned ADO projects.
Add 'pool: vmImage: ubuntu-latest' so it routes to the hosted pool.

create_ado_pipelines.sh called 'az pipelines create' without --queue-id,
which can fail with 'Could not queue the build' on new projects where
the default queue association is not yet established. Resolve the
queue ID dynamically by name (default 'Azure Pipelines'), with
AGENT_POOL_NAME env var override for self-hosted pools.

Also add a Troubleshooting section to deployguide_ado.md covering the
most common failure modes reported by accelerator users:
- Hosted parallelism not granted (aka.ms/azpipelines-parallelism-request)
- Missing 'Create build pipeline' permission
- Stale folders/repos blocking initialise-project retry
- Retired ubuntu-20.04 image
- Queue association failure on new projects

Reported by Vicky Arpatzoglou via accelerator feedback.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants