Skip to content

StageFreight Azure DevOps Integration

Status: experimental. Render and the forge client are implemented and unit-tested but not yet validated against a live Azure DevOps run. This is the setup to do that validation. See the checklist at the bottom.

CI Pipeline

CI files are generated by StageFreight, not hand-maintained.

stagefreight ci render azuredevops --write
git add azure-pipelines.yml
git commit

Audition enforces freshness — a stale azure-pipelines.yml fails the pipeline.

Runner Infrastructure

k8s/stagefreight-azure-agent.yaml

A self-hosted Azure DevOps agent in Kubernetes with persistent buildkitd (fast image builds) and dind (Docker-dependent ops). It is the k8s analog of the GitLab runner-compose.buildkitd.yml, with the same trust split:

component access
agent runs jobs (the StageFreight CI image as the container: job)
build jobs BUILDKIT_HOST=tcp://127.0.0.1:1234 — independent mTLS PKI
docker jobs DOCKER_HOST=tcp://127.0.0.1:2376 — DinD TLS
other jobs no daemon access

Compose shares one Docker network; in k8s the three run in one pod and share localhost, which is why the builders are reached on 127.0.0.1 rather than the buildkitd/dind service names GitLab uses.

Setup

  1. Create an agent pool in Azure DevOps: Project settings → Agent pools → Add pool (self-hosted). Note the pool name.
  2. Create a PAT with Agent Pools (read & manage).
  3. Build an agent image per Microsoft's Run a self-hosted agent in Docker guide, push it to a registry your cluster can pull.
  4. Edit k8s/stagefreight-azure-agent.yaml: set AZP_URL, AZP_TOKEN, AZP_POOL, and the agent image (REPLACE_WITH_AZP_AGENT_IMAGE).
  5. Apply: kubectl apply -f k8s/stagefreight-azure-agent.yaml
  6. Confirm the agent appears Online in the pool, then run a pipeline that uses pool: { name: <your pool> }.

How it works

Every job calls stagefreight ci run <phase>. StageFreight reads .stagefreight.yml and decides what each phase does at runtime; the generated azure-pipelines.yml is transport, StageFreight owns the logic — identical to every other forge.

Validation checklist (graduate from experimental)

This topology is proven on GitLab; the Azure-specific pieces still need a real run:

  • [ ] Agent registers and shows Online.
  • [ ] A container: ci job can reach 127.0.0.1:1234 (buildkitd) and :2376 (dind). If Azure runs the container job on an isolated Docker network, you may need to drop the container: and run StageFreight directly on the agent, or wire host networking — this is the main thing to verify.
  • [ ] DinD has generated /certs/client before the first build (init ordering).
  • [ ] stagefreight ci run perform builds via buildkitd (mTLS handshake succeeds).
  • [ ] The forge client ops work against the real org (auth, refs, commits, tags, PRs). Releases are intentionally ErrNotSupported (Azure has no native git-release).

Capture what you change here so the next person doesn't rediscover it — that's what moves Azure from experimental to supported.