Feature/OIDC acr migration#1001
Conversation
- Replace docker/login-action (admin credentials) with az acr login via OIDC session (azure/login with AZURE_CLIENT_ID) - Add --registry-identity and --user-assigned flags to az containerapp up so identity attachment and registry config happen atomically on create and update, eliminating the chicken-and-egg ordering issue - Replace az config set extension.use_dynamic_install with explicit az extension add --name containerapp --upgrade to ensure the extension version supports --registry-identity on az containerapp up - Remove --registry-username/--registry-password from containerapp up - Update Assign MI step to use WEB_UAMI_RESOURCE_ID and WEB_UAMI_CLIENT_ID
…pdate - Add --image to az containerapp update so image and env vars are set atomically in a single revision (dev and prod) - Remove separate containerapp up which required CAE-level permissions; identity assign + registry set + update --image are CA-scoped only (plus managedEnvironments/read, covered by Container Apps Contributor role on the CAE granted to deploy UAMIs)
…_APP_ENVIRONMENT env var - Change deploy-production cancel-in-progress from true to false to prevent broken state if deploy is cancelled mid-flight (secrets set but revision not yet updated) - Remove unused CONTAINER_APP_ENVIRONMENT env var from both dev and prod Assign MI steps (vestigial from az containerapp up era)
There was a problem hiding this comment.
Pull request overview
Updates the GitHub Actions deployment workflow to use Azure OIDC + managed identity for Azure Container Registry (ACR) auth and Container App registry configuration, removing the need for ACR username/password secrets.
Changes:
- Switch Azure login to use a standardized
AZURE_CLIENT_IDsecret (env-scoped). - Replace
docker/login-action(ACR username/password) withaz acr login, and configure Container App identity + registry viaaz containerapp .... - Change production deploy concurrency to allow overlapping runs (
cancel-in-progress: false).
| az containerapp identity assign --name $CONTAINER_APP_NAME --resource-group $RESOURCEGROUP --user-assigned ${{ secrets.WEB_UAMI_RESOURCE_ID }} | ||
| az containerapp registry set --name $CONTAINER_APP_NAME --resource-group $RESOURCEGROUP --server $CONTAINER_REGISTRY --identity ${{ secrets.WEB_UAMI_RESOURCE_ID }} | ||
|
|
||
| - name: Assign Managed Identity to Container App and Set Secrets and Environment Variables |
There was a problem hiding this comment.
The step name says it assigns a managed identity, but the identity assignment was moved to the prior step. Rename this step to reflect what it now does (setting Key Vault-backed secrets and updating Container App env vars/image) to avoid confusion during ops/debugging.
| - name: Assign Managed Identity to Container App and Set Secrets and Environment Variables | |
| - name: Set Key Vault-backed secrets and update Container App environment variables and image |
| concurrency: | ||
| group: deploy-production | ||
| cancel-in-progress: true | ||
| cancel-in-progress: false |
There was a problem hiding this comment.
Setting cancel-in-progress: false for the production deploy concurrency group allows multiple production deployments to run at the same time. Because both runs mutate the same Container App (identity/registry/secrets/image), overlapping runs can race and leave production on an unexpected image or env-var set. Consider reverting to cancel-in-progress: true (or use a more granular concurrency group keyed by environment/app name if parallelism is needed).
| cancel-in-progress: false | |
| cancel-in-progress: true |
| az containerapp identity assign --name $CONTAINER_APP_NAME --resource-group $RESOURCEGROUP --user-assigned ${{ secrets.WEB_UAMI_RESOURCE_ID }} | ||
| az containerapp registry set --name $CONTAINER_APP_NAME --resource-group $RESOURCEGROUP --server $CONTAINER_REGISTRY --identity ${{ secrets.WEB_UAMI_RESOURCE_ID }} | ||
|
|
||
| - name: Assign Managed Identity to Container App and Set Secrets and Environment Variables |
There was a problem hiding this comment.
The step name says it assigns a managed identity, but the identity assignment was moved to the prior step. Rename this step to reflect what it now does (setting Key Vault-backed secrets and updating Container App env vars/image) to avoid confusion during ops/debugging.
| - name: Assign Managed Identity to Container App and Set Secrets and Environment Variables | |
| - name: Set Key Vault-backed Secrets and Update Container App Environment Variables and Image |
Description
Describe your changes here.
Fixes #Issue_Number (if available)
Ensure that your pull request has followed all the steps below: