azdo-extension CI fails on self-hosted agents: npm cannot reach registry.npmjs.org (EPERM egress block)

[vhvb1989]

Summary

The azure-dev - azdo-extension pipeline (eng/pipelines/release-azuredevops.yml → azuredevops-build-and-test.yml → azuredevops-build.yml) consistently fails on the self-hosted Linux and Windows azsdk-pool agents because npm cannot reach the public registry.

Actual error (from the ADO build logs)

• Linux — Install build tools and dependencies step (npm i -g npm tfx-cli; npm ci):

  npm error code EPERM
  npm error FetchError: request to https://registry.npmjs.org/npm failed, reason:
  npm error The operation was rejected by your operating system.
  

• Windows — Test step: 'tsc' is not recognized ... — a cascade of the same failed/incomplete npm ci.

The very first command to fail is npm i -g npm itself — before any project dependency is resolved.

Scope / evidence this is environmental, not code

• Build Mac passes — it runs on the hosted Azure Pipelines pool (open internet). Linux/Windows run on the self-hosted azsdk-pool.
• The vscode pipeline uses the identical npm i -g npm …; npm ci pattern and passed on the same azsdk-pool concurrently.
• Dependabot PR chore(deps): bump adm-zip and azure-pipelines-task-lib in /ext/azuredevops/setupAzd #9215 (unrelated dep bump) failed identically.
• npm ci, npm test (tsc + mocha) and ci-package.ps1 (tsc + tfx extension create) all pass locally on Node 20.
• Prior azdo dependency PRs (fix(deps): resolve 6 open Dependabot security alerts #8865, chore(deps-dev): bump js-yaml from 4.1.1 to 4.3.0 in /ext/azuredevops/setupAzd #8853, ~Jun 30) passed; PRs from Jul 20–21 fail — indicating a recent environmental change.
• A manually re-queued build reproduced the same EPERM (3/3 azdo runs fail; Mac passes each time), so it is not transient flakiness.

Temporary mitigation

To unblock unrelated PRs (e.g. the grouped Dependabot security update #9240), the npm-dependent steps of the azdo-extension build have been made non-blocking for PR validation builds only (Build.Reason == PullRequest). Release/CD builds on main remain strict, so CodeQL and artifact generation are unaffected.

Follow-up (this issue)

• Root-cause and fix the npm egress block on the self-hosted azsdk-pool Linux/Windows agents (allow registry.npmjs.org, or route the azdo-extension build through an allowlisted internal npm feed / Azure Artifacts, consistent with the working vscode build).
• Re-enable the azdo-extension PR gate as blocking (revert the continueOnError / PR guards added in chore(deps): group all Dependabot security updates into a single PR #9240 to eng/pipelines/templates/jobs/azuredevops-build.yml).

[vhvb1989]

Full scope of the PR-only mitigation applied in #9240

The mitigation ended up touching three files (all should be reverted / revisited when the egress issue is fixed and the gate is made blocking again):

1. eng/pipelines/templates/jobs/azuredevops-build.yml — npm-dependent steps use continueOnError: ${{ eq(variables['Build.Reason'], 'PullRequest') }}; the VSIX staging step + pipelineArtifact output are guarded with ne(variables['Build.Reason'], 'PullRequest').
2. eng/pipelines/templates/stages/azuredevops-sign.yml — the Sign stage is now gated with condition: in(variables['Build.Reason'], 'IndividualCI', 'BatchedCI', 'Manual'). Required because once BuildAndTest completes with issues (instead of hard-failing) on PRs, the Sign stage began running and failed on DownloadPipelineArtifact (no vsix on PR builds).
3. eng/pipelines/release-azuredevops.yml — added the azdo build/sign/publish stage templates to the pipeline's pr/trigger path filters so edits to these templates are validated by the pipeline (previously only ext/azuredevops and the root pipeline file triggered it). This one is a genuine improvement and can likely stay.

Verified on PR #9240: build now reports BuildAndTest = succeededWithIssues, Sign/PublishManual = skipped, overall = partiallySucceeded → the azure-dev - azdo-extension GitHub check passes while the underlying agent egress issue remains unresolved.