Implement CI/CD for Foundry hosted agents

Why it matters

Agents depend on each other, so a release has to promote and restore a compatible set of versions, not one agent at a time.

What to practise

Keep three version identities apart: a logical semantic version, an immutable Foundry hosted-agent version, and a Container Apps revision. Configure GitHub OIDC and protected environments for separate development, staging, and production Foundry projects. Bump the scanner’s version in a pull request and check its contract evidence. After merge, watch the dashboard split traffic 75/25 between stable and candidate revisions, and use the label URLs to verify each one. Promote a healthy candidate to 0/100, then trigger a regression and restore the last verified release set in reverse dependency order. Foundry itself does no weighted routing here.

How it fits

Canary and blue/green at the dashboard are 4.3.1, and per-environment projects and release sets are 4.3.2. Evidence-based promotion with approvals is 4.3.3, the rollback is 4.3.4, and the OIDC identity separate from approval is 4.3.8.