fix(ops): починить provision-prod.sh + доки под живой прод - #7
Conversation
The first prod provisioning died halfway: I wrote `-d` for the database name where the CLI wants `-n`, so it failed AFTER creating the RG, ACR and the Postgres server — the slow part. Re-running would have tried to recreate them. - fixed the flag; the script now guards ACR / PG server / env / identities / roles / federated credentials with existence checks, so it resumes instead of colliding. - CLAUDE.md: status is now PROD (was "инфраструктуры нет"), debugging section points at ACA logs instead of the local compose that no longer exists, and records the OIDC gotcha. Prod verified live: revision Healthy/RunningAtMaxScale, ingress None, 1/1 replica, @launch_11_bot polling, zero 409 conflicts. Co-Authored-By: Claude <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2451edb1ff
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| az postgres flexible-server db create -g "$RG" -s "$PG" -n "$PGDB" -o none 2>/dev/null \ | ||
| || echo " (БД уже есть)" |
There was a problem hiding this comment.
Preserve real database-creation failures
On a rerun, any database-creation failure—not only an AlreadyExists response—is converted to success here. For example, a transient Azure error, expired authorization, or a server that is not ready will be reported as “БД уже есть”; nothing later verifies that the database exists, so the script stores a DATABASE_URL for it and ultimately reports that provisioning succeeded while the deployed bot cannot connect. Check for the database explicitly or suppress only the expected conflict.
Useful? React with 👍 / 👎.
| az role assignment create --assignee-object-id "$CI_PRINCIPAL" --assignee-principal-type ServicePrincipal \ | ||
| --role "Contributor" --scope "$RG_ID" -o none | ||
| --role "Contributor" --scope "$RG_ID" -o none 2>/dev/null || echo " (роль уже есть)" |
There was a problem hiding this comment.
Fail when required role assignment cannot be created
If assigning Contributor fails for any reason other than an existing assignment—for example insufficient role-assignment privileges, throttling, or a transient API error—this handler prints that the role already exists and continues through the success message. The deploy workflow relies on this CI identity to create or update the Container App, so subsequent deployments will fail despite provisioning appearing successful; explicitly query the assignment or suppress only the AlreadyExists error. The same unrestricted suppression is also used for AcrPull, Managed Identity Operator, and the federated credentials.
Useful? React with 👍 / 👎.
Скрипт провижининга
Первый прогон упал на середине: я написал
-dдля имени БД, а CLI требует-n. Упал после создания RG, ACR и PG-сервера — самого долгого. Повторный запуск попытался бы пересоздать их.Доки под факт
CLAUDE.mdбота говорил «прод-инфраструктуры нет» — теперь ПРОД с 2026-07-17. Секция отладки ссылалась на локальный docker-compose, которого больше нет → переписана на логи ACA. Записана грабля OIDC.Прод проверен живьём
🤖 Generated with Claude Code