Upgrade the v1 Cloud SQL schema and seed the v2 database side by side in the release run
Maintainer thường phản hồi trong vòng 2 ngày
Đánh giá
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 25/100
Hướng nghiên cứu
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.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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).
- Ngôn ngữ chính
- Python
- Star
- 18
- Fork
- 33
- Merge trung bình
- 2 ngày 7 giờ
- Pull request đã merge (30 ngày)
- 64
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của PolicyEngine/policyengine-api
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
PolicyEngine/policyengine-api#4037 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 88/100
PolicyEngine/policyengine-api#3911 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 82/100
PolicyEngine/policyengine-api#3910 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Split the release tests over six runners, and stop repeating the merge run's checks on the release commitCó thể đã có người làm @anth-volk đã nhận hôm nay. Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 25/100
PolicyEngine/policyengine-api#4133 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Serve household reports at /v2/reportsCó thể đã có người làm Có pull request liên kết đang mở hoặc đã được merge. Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
PolicyEngine/policyengine-api#4131 ·
Maintainer thường phản hồi trong vòng 2 ngày
Tất cả issue của PolicyEngine/policyengine-api
Issue tương tự
-
Admin member of a research group cannot see the HX2 allocation until they've been added to itĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
Maintainer thường phản hồi trong vòng 2 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
developmentseed/titiler-cmr#278 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 2 ngày