Three Workflows, One Rule

Starts a postgres:16 service container, loads sql/metals-db.sql into it with psql, then runs pytest metals_api/tests against that real database. This is the only job with no if: — it always runs, which is the point: every push and every PR gets tested.

Logs in to Azure with azure/login, then runs a single command:

az acr build --registry "$REGISTRY_NAME" --resource-group "$RESOURCE_GROUP" \
  --image "metals-api:$IMAGE_TAG" --file metals_api/Dockerfile .

The build happens on Azure's own build agents, not the GitHub runner — the runner only uploads the source. That's why no Docker setup step is needed, and why the image never travels across the internet twice.

Points the Web App at the image, restarts it, then polls /health up to ten times with a ten-second wait, failing the run with ::error:: if it never returns 200. Its environment: block includes a url:, so the deployed address is linked directly from the run summary and the repository's Environments view.

It declares contents: none and skips actions/checkout entirely — this job never needs repository files, only the Azure CLI and its OIDC token.

Editing a stylesheet under metals_ui/ triggers only the UI workflow; changing a route under metals_api/ triggers only the API's. Each app ships on its own schedule, and an unrelated change can't cause an unnecessary restart of the other.

The UI has no automated test suite, so on pushes and PRs its build job runs a plain docker build on the runner — no registry, no Azure login, no credentials involved. It proves the image still builds, which is the useful signal available here.

That validation job is deliberately a separate job from build-and-push rather than one job with conditional steps, because environment: is a job-level setting — keeping them apart means an ordinary PR never touches the Development environment or its protection rules.

The UI's az acr build step sets its working directory before running. That's not cosmetic: az acr build validates the --file path against the current directory rather than the source argument, so running it from the repository root with --file Dockerfile metals_ui fails with Unable to find 'Dockerfile'. The same workaround appears in the manual deploy script.

Runs fmt -check, init -backend=false, validate, and test for both the main configuration and the bootstrap module, then the Python unit tests for the schema loader. Everything here is offline — it never authenticates to Azure and can never change a resource.

Guarded by if: github.event_name == 'workflow_dispatch'. It checks that every required secret and variable is actually set before doing anything, connects Terraform to its remote state in Azure Blob Storage, produces a plan, and applies that same plan in the same run if the operation wasn't plan.

The operation defaults to plan, so the least destructive choice is the one you get by clicking through without thinking.

To load the database schema after an apply, the runner must reach PostgreSQL — but GitHub's runners have unpredictable IP addresses. The workflow looks up its own public IP, adds a firewall rule named after the run, initializes the database, and removes the rule in a cleanup step marked if: always() so it runs even when the initialization failed.

After an apply it appends the Terraform outputs to $GITHUB_STEP_SUMMARY — the client/tenant/subscription IDs for the application deployment identity, both Web App names, and the registry login server. Those are the values that go into the Development environment's secrets, covered on the next page.