Upgrade the v1 Cloud SQL schema and seed the v2 database side by side in the release run
I maintainer di solito rispondono entro 2 giorni
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 25/100
Direzione di ricerca
Read the workflow files migrate-v1-cloud-sql.yml and seed-v2-database.yml, then inspect the staging and candidate deploy dependencies described in the issue. Start by comparing the staging and production job dependencies; done means both database jobs can start together in each environment, candidates still wait for both, and the migration skill documents the parallel order and partial-upgrade outcome. Pull request #4130 is already open.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Problem
In a Public API release run, seed-v2-staging-database needs migrate-v1-staging-cloud-sql, and seed-v2-production-database needs migrate-v1-production-cloud-sql, so each environment's v1 schema upgrade (about 2 minutes) and v2 seeding (about 6 minutes) run one after the other, on the path to production.
Neither job reads the other's database:
migrate-v1-cloud-sql.ymlsigns in to Google Cloud with the database migration service account, starts the Cloud SQL Auth Proxy, and runsmigrate_v1_cloud_sql.sh, which reads the Cloud SQL migration credentials from Secret Manager, takes a backup when revisions are pending, upgrades and verifies the v1 schema.seed-v2-database.ymlhas no Google Cloud sign-in, no Cloud SQL proxy and no v1 credentials. Its steps (validate_database_environment.sh supabase, the threequalify_v2_*scripts,migrate_v2_metadata_schema.sh,reconcile_v2_privileges.pyandpublish_v2_metadata_catalog.py) read onlyV2_MIGRATION_DATABASE_URLorV2_DATA_WRITE_DATABASE_URL, and import only v2 modules.
The order came in with the Stage 9 catalog (#3808, 78e380bbd), when the seeding job's predecessor waited for the single v1 upgrade job of the time; the production one did not wait for any v1 upgrade. #3813 (f410bcac1) split the v1 upgrade per environment and made both seeding jobs wait for theirs. Neither pull request nor the migration docs give a reason; docs/migration/stage-10-v2-policies.md and stage-11-v2-households.md only require both schemas before the candidate is built.
Expected behaviour
- In each environment, the v1 upgrade and the v2 seeding start together.
- Each Cloud Run candidate deploy needs both, so no candidate is built until both databases are upgraded.
deploy-cloud-run-stagingalready needs both;deploy-cloud-run-candidateneeds the production v1 upgrade as well as the production seeding. - Both jobs keep their environments (
staging-databaseorproduction-databasefor the v1 upgrade,stagingorproductionfor the seeding) andsecrets: inherit. docs/engineering/skills/alembic-migrations.mdrecords the order, and that a release that stops can leave either database upgraded without the other.
Expected saving: about 3.8 minutes per release (the measured v1 upgrade times, 2.0 in staging and 1.8 in production).
- Lingua principale
- Python
- Stelle
- 18
- Fork
- 33
- Merge medio
- 2g 7h
- PR unite (30g)
- 64
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di PolicyEngine/policyengine-api
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
PolicyEngine/policyengine-api#4037 ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 1/5 1-3 ore Idoneità per principianti 88/100
PolicyEngine/policyengine-api#3911 ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 82/100
PolicyEngine/policyengine-api#3910 ·
I maintainer di solito rispondono entro 2 giorni
-
Split the release tests over six runners, and stop repeating the merge run's checks on the release commitForse già presa @anth-volk l’ha presa oggi. Aperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
PolicyEngine/policyengine-api#4133 ·
I maintainer di solito rispondono entro 2 giorni
-
Serve household reports at /v2/reportsForse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
PolicyEngine/policyengine-api#4131 ·
I maintainer di solito rispondono entro 2 giorni
Tutte le issue di PolicyEngine/policyengine-api
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
-
Validate finite output clamping limits in StepPredictor.prepare_clamping_params to prevent silent NaN/Inf propagationForse già presa @muskan-creates352 l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
mllam/neural-lam#848 ·
I maintainer di solito rispondono entro 2 giorni
-
infra
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
fab-geocommuns/RNB-coeur#1166 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
deepspeedai/DeepSpeed#8951 ·
I maintainer di solito rispondono entro 2 giorni