Upgrade the v1 Cloud SQL schema and seed the v2 database side by side in the release run
Los mantenedores suelen responder en 2 días
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 25/100
Línea de trabajo
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.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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).
- Lenguaje dominante
- Python
- Estrellas
- 18
- Forks
- 33
- Merge medio
- 2 d 7 h
- PR fusionados (30 d)
- 64
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de PolicyEngine/policyengine-api
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
PolicyEngine/policyengine-api#4037 ·
Los mantenedores suelen responder en 2 días
-
Dificultad 1/5 1-3 horas Aptitud para principiantes 88/100
PolicyEngine/policyengine-api#3911 ·
Los mantenedores suelen responder en 2 días
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 82/100
PolicyEngine/policyengine-api#3910 ·
Los mantenedores suelen responder en 2 días
-
Split the release tests over six runners, and stop repeating the merge run's checks on the release commitPosiblemente ocupada @anth-volk la tomó hoy. Abierto
Dificultad 4/5 3-5 días Aptitud para principiantes 25/100
PolicyEngine/policyengine-api#4133 ·
Los mantenedores suelen responder en 2 días
-
Serve household reports at /v2/reportsPosiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abierto
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
PolicyEngine/policyengine-api#4131 ·
Los mantenedores suelen responder en 2 días
Todos los issues de PolicyEngine/policyengine-api
Issues similares
-
Admin member of a research group cannot see the HX2 allocation until they've been added to itAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
Los mantenedores suelen responder en 2 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
Los mantenedores suelen responder en 2 días
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
developmentseed/titiler-cmr#278 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
Los mantenedores suelen responder en 2 días