Problem Statement
The ACN scheduled release workflow (and future automation) needs to monitor Azure DevOps pipeline status from GitHub Actions. Currently, there's no authenticated path from GitHub → ADO API for the msazure/One project.
Use Cases
- Scheduled release workflow — After tag creation, monitor ACN PR Pipeline and CNI Release Test completion
- Future automation — Any GitHub workflow that needs to know if an ADO pipeline passed/failed
- PR gating — Could enable GitHub merge queue to wait for ADO pipeline results
Options Explored
| # |
Approach |
Status |
| 1 |
OIDC SP → ADO API (direct polling) |
❌ Blocked — needs ADO org admin to add SP |
| 2 |
ADO → GitHub bridge (GitHub App posts statuses) |
✅ Proven on fork — recommended short-term |
| 3 |
PAT-based auth |
❌ Rejected — 5-day expiry, not viable |
| 4 |
Reuse Build Validations SP |
❌ Rejected — overscoped (full sub access) |
| 5 |
Migrate ADO tests to GH workflows |
🔮 Long-term — eliminates auth problem entirely |
Recommended: Option 2 (ADO → GitHub Bridge)
Architecture:
Tag push → ADO auto-triggers pipeline (native service connection)
→ ADO pipeline posts "pending" commit status to GitHub (via GitHub App)
→ ADO pipeline finishes → posts "success"/"failure" to GitHub
→ GitHub workflow polls: gh api commits/<sha>/statuses
→ No ADO API access needed from GitHub side
Steps:
- Create GitHub App with
statuses:write on Azure/azure-container-networking
- Add App ID + private key as secret variables in ADO pipelines
- Add status-posting steps to
.pipelines/pipeline.yaml and .pipelines/cni/pipeline.yaml
- Update scheduled release workflow to poll GitHub commit statuses
Security: Low risk — App only has statuses:write (cosmetic), secrets live in ADO only, pipelines only trigger on protected refs.
Precedent: Same pattern used by cilium-private repo.
Long-term: Option 5 (Migrate to GH Workflows)
Suggested by @QxBytes — if E2E tests ran as GitHub Actions workflows:
GITHUB_TOKEN natively polls workflow status (zero auth setup)
- Tag push triggers workflows same as ADO
- Copilot agents work better with GH workflows
- Test workloads mainly interact with AKS clusters — portable
Effort: Large (rewrite pipeline YAML). Timeline: Weeks/months.
ADO Pipeline Details
| Pipeline |
File |
Trigger |
| ACN PR Pipeline |
.pipelines/pipeline.yaml |
PR, merge queue, tags, nightly |
| CNI Release Test |
.pipelines/cni/pipeline.yaml |
Tags (v*, dropgz/*, azure-ipam/*) |
| GitHub Release |
Def 393797 in msazure/One |
Manual |
Contacts
- Build Validations SP owners: @MiguelGo, @QxBytes (John Payne)
- ADO org:
msazure, Project: One
acn-release-bot SP: App ID 75013c7b-3bea-441b-952c-e13d7c9247bc (Object ID 29d8f13a-6ba6-4374-ad34-9cf875064d74)
Related
Problem Statement
The ACN scheduled release workflow (and future automation) needs to monitor Azure DevOps pipeline status from GitHub Actions. Currently, there's no authenticated path from GitHub → ADO API for the
msazure/Oneproject.Use Cases
Options Explored
Recommended: Option 2 (ADO → GitHub Bridge)
Architecture:
Steps:
statuses:writeonAzure/azure-container-networking.pipelines/pipeline.yamland.pipelines/cni/pipeline.yamlSecurity: Low risk — App only has
statuses:write(cosmetic), secrets live in ADO only, pipelines only trigger on protected refs.Precedent: Same pattern used by
cilium-privaterepo.Long-term: Option 5 (Migrate to GH Workflows)
Suggested by @QxBytes — if E2E tests ran as GitHub Actions workflows:
GITHUB_TOKENnatively polls workflow status (zero auth setup)Effort: Large (rewrite pipeline YAML). Timeline: Weeks/months.
ADO Pipeline Details
.pipelines/pipeline.yaml.pipelines/cni/pipeline.yamlv*,dropgz/*,azure-ipam/*)msazure/OneContacts
msazure, Project:Oneacn-release-botSP: App ID75013c7b-3bea-441b-952c-e13d7c9247bc(Object ID29d8f13a-6ba6-4374-ad34-9cf875064d74)Related
wait-pipelineCLI ready for Option 1)