Fix Linux CI registry authentication before network isolation

build/yaml/jobs/linux/binaries.yaml

@@ -28,6 +28,12 @@ jobs:
   workspace:
     clean: outputs
 
+  ${{ if eq(parameters.OneESPT, true) }}:
+    templateContext:
+      authenticatedContainerRegistries:
+      - armServiceConnection: 'VS Diagnostics Dev (ProdDiagBuild)'
+        acrName: proddiagbuild
+
   steps:
   - checkout: self
     clean: true

build/yaml/steps/linux/binaries.yaml

@@ -3,15 +3,19 @@
 
 # Step Template: Build Linux Binaries
 
+parameters:
+  OneESPT: false
+
 steps:
-# Login to ACR
-- task: AzureCLI@2
-  displayName: Docker Login
-  inputs:
-    azureSubscription: 'VS Diagnostics Dev (ProdDiagBuild)'
-    scriptType: bash
-    scriptLocation: inlineScript
-    inlineScript: 'az acr login --name proddiagbuild'
+# 1ES authenticates through the job's templateContext before network isolation.
+- ${{ if ne(parameters.OneESPT, true) }}:
+  - task: AzureCLI@2
+    displayName: Docker Login
+    inputs:
+      azureSubscription: 'VS Diagnostics Dev (ProdDiagBuild)'
+      scriptType: bash
+      scriptLocation: inlineScript
+      inlineScript: 'az acr login --name proddiagbuild'
 
 # Restore vcpkg source and binary caches
 - task: Cache@2

docs/build.md

@@ -29,6 +29,12 @@ The yaml files are located in the $RepoRoot$/build/yaml folder. The code is stru
   * Jobs/Binaries.yaml and Jobs/Packages.yaml reference the corresponding files in the Windows and Linux folders for parallelization
 * Steps – The task to run (eg. Nuget restore, msbuild solution, copy files).
 
+Linux binary jobs running under 1ES authenticate to the build-image registry through
+`templateContext.authenticatedContainerRegistries`, before network isolation starts.
+Keep this authentication in the job context rather than adding an `az acr login` user
+step: network isolation blocks that login to `proddiagbuild.azurecr.io`. Non-1ES
+pipelines retain an explicit Azure CLI login step.
+
 We restrict access of running the above builds to Microsoft and close contributors as to avoid malicious code from running. The signed build requires internal processes (signing and security checks) and will not be exposed to the public. If you require
 modifications or changes to the build, you are free to update the yaml files.