Upgrade the v1 Cloud SQL schema and seed the v2 database side by side in the release run
Les mainteneurs répondent en général sous 2 jours
Évaluation
- Difficulté
- 3/5
- Temps estimé
- 1-2 jours
- Accessibilité débutants
- 25/100
Piste de recherche
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.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
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).
- Langage dominant
- Python
- Étoiles
- 18
- Forks
- 33
- Merge moyen
- 2 j 3 h
- PR mergées (30 j)
- 72
Préparer son environnement
- Aucun Dockerfile ni fichier Docker Compose
- Propose un modèle de pull request
- Lire le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de PolicyEngine/policyengine-api
-
Difficulté 2/5 1-3 heures Accessibilité débutants 76/100
PolicyEngine/policyengine-api#4037 ·
Les mainteneurs répondent en général sous 2 jours
-
Difficulté 1/5 1-3 heures Accessibilité débutants 88/100
PolicyEngine/policyengine-api#3911 ·
Les mainteneurs répondent en général sous 2 jours
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 82/100
PolicyEngine/policyengine-api#3910 ·
Les mainteneurs répondent en général sous 2 jours
-
Run the full-catalog integration tests only when a change can affect themPeut-être pris @anth-volk l’a pris aujourd’hui. Ouverte
Difficulté 4/5 3-5 jours Accessibilité débutants 25/100
PolicyEngine/policyengine-api#4149 ·
Les mainteneurs répondent en général sous 2 jours
-
Split the pull request tests into the same six shards as the release testsPeut-être pris @anth-volk l’a pris aujourd’hui. Ouverte
Difficulté 4/5 3-5 jours Accessibilité débutants 25/100
PolicyEngine/policyengine-api#4144 ·
Les mainteneurs répondent en général sous 2 jours
Toutes les issues de PolicyEngine/policyengine-api
Issues similaires
-
Difficulté 2/5 1-3 heures Accessibilité débutants 82/100
Les mainteneurs répondent en général sous 1 jour
-
Claiming namespace `thejakia1`Ouvertenamespace operations
Difficulté 1/5 Moins d'une heure Accessibilité débutants 65/100
EclipseFdn/open-vsx.org#15057 ·
Les mainteneurs répondent en général sous 1 jour
-
Mission statement: why this is free, in the README, Why This Exists and the wiki HomePeut-être pris @ChiefGyk3D l’a pris aujourd’hui. Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 76/100
ChiefGyk3D/Clouds-Against-Humanity#348 ·
Les mainteneurs répondent en général sous 1 jour
-
[Perf] Default --vllm-watermark 0.05 for rollouts (hybrid models re-preempt under KV pressure)Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 74/100
vllm-project/vime#508 ·
Les mainteneurs répondent en général sous 4 jours
-
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
Les mainteneurs répondent en général sous 1 jour