ci: make Azure Pipelines PR triggers explicit

[Carter Tinney (cartertinney)]

Summary

• explicitly enable CI for pushes to main in the Build, Python E2E, and DPS E2E Azure Pipelines
• explicitly enable PR validation for PRs targeting main
• align their checked-in trigger configuration with Horton E2E

Why

Horton E2E declared its trigger and pr filters in YAML, while Build, Python E2E, and DPS E2E relied on implied or pipeline UI configuration. This produced inconsistent checked-in configuration and made trigger behavior harder to diagnose. In particular, same-repository Dependabot PRs ran Horton and DPS but did not run Python E2E.

Keeping the branch triggers explicit and identical makes the intended behavior versioned and reviewable. Azure DevOps pipeline settings can still impose stricter organization, project, or pipeline-level fork policies.

Build pipeline incident

The separate absence of the Azure.azure-iot-sdk-python status was not caused by this YAML change. Azure DevOps definition 330 had been changed from queueStatus: enabled in revision 35 to queueStatus: disabled in revision 36 on August 27. The YAML path and trigger filters were unchanged.

The definition has been re-enabled in Azure DevOps as revision 37. A fresh synchronization event for this PR queued Build 162892 and posted the required GitHub status successfully.

External contributor security configuration

Fork approval policy cannot be expressed in pipeline YAML. In Azure DevOps, configure Project Settings > Pipelines > Settings > Triggers to securely build fork PRs, and configure each pipeline to require a team member's comment for fork PRs while allowing same-repository PRs to run automatically.

This allows Dependabot PRs to run automatically because Dependabot creates branches in this repository, while external fork PRs wait for a maintainer to trigger them with /azp run.

Secrets and regular-build permissions should remain unavailable to fork builds. Resource-dependent E2E pipelines may therefore require a trusted internal branch after review if their service connections are unavailable to the secure fork build.

Validation

• parsed all four affected/related Azure Pipelines YAML files with PyYAML
• verified Build, Python E2E, DPS E2E, and Horton E2E now have identical trigger blocks
• ran git diff --check
• verified VS Code reports no YAML problems
• verified a fresh PR event queued and started Azure.azure-iot-sdk-python Build 162892

[Carter Tinney (cartertinney)]

/azp run Python E2E

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[Carter Tinney (cartertinney)]

ADO configuration follow-up:

• Python E2E definition 426 was using the legacy OAuth service connection, so it published an identity-less commit status that could not satisfy the required check bound to the Azure Pipelines GitHub App.
• Definition 426 is now on the same InstallationToken service connection used by Build and DPS (revision 32).
• Verification Build 162896 is publishing Python E2E as a GitHub check run from Azure Pipelines app ID 9426, matching branch protection.

[Carter Tinney (cartertinney)]

/azp run horton-e2e-python

[Carter Tinney (cartertinney)]

/AzurePipelines run horton-e2e-python