Staging deployments do not promote their tested Simulation Entrypoint revision
维护者通常 1 天内回复
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 35/100
调研方向
Read .github/workflows/simulation-deploy.yml and .github/workflows/stage12-deploy.yml, then trace the staging promotion checks and cleanup rules described in the issue. Confirm how the operator's initial traffic move affects the stable-URL check before changing the staging settings. Done means both staging paths promote the tested revision, a registered rule enforces promotion, and the existing rollback and checks still work.
由索引模型根据 Issue 内容生成。
描述
What
Staging deployments of the Simulation Entrypoint test a tagged Cloud Run candidate but never move the staging service's stable traffic to it. Both the beta job in simulation-deploy.yml and the staging job of the Stage 12 comparison path workflow (stage12-deploy.yml) pass promote_entrypoint: false. Production deployments pass true.
As a result, the staging service's stable URL does not serve the build that passed the staging tests. Today it serves Cloud Run's sample container (revision 00001-cuh), whose /health returns an HTML page with no revision header, and every tested staging build exists only behind a tagged URL that receives no stable traffic.
Why it matters
Any caller that uses the staging stable URL reaches an untested build, or the sample container, instead of the build the deployment tested. This prevents staging callers, such as the Public API's staging service, from running their own staging checks against staging simulation infrastructure.
Wanted result
- Every staging deployment promotes its tested entrypoint revision to the staging service's stable traffic, as production does, using the same checks: exact revision change, stable-URL checks, authentication checks and restoring the previous revision on failure.
- A registered rule requires it, so a staging deployment cannot go back to leaving stable traffic unchanged.
- Expected side effect: after the first promotion, the existing clean-up deletes the staging service's older revisions (about 67 today), keeping only the promoted revision and the one it replaced.
Order
Before the change merges, an operator must move the staging stable traffic off the sample container onto a tested staging revision. Otherwise the first promotion's stable-URL check fails on the sample container's response, restores it, and fails the beta deployment, which stops the production deployment.
- 主要语言
- Python
- 星标
- 1
- 派生
- 1
- 平均合并
- 1 天 16 小时
- 30 天内合并 PR
- 60
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
PolicyEngine/policyengine-sim-api 的其他 Issue
-
Update policyengine to 6.7.3可能重新可做 关联的 PR 已关闭且未合并。 未关闭
难度 2/5 半天 新手友好度 70/100
PolicyEngine/policyengine-sim-api#823 ·
维护者通常 1 天内回复
-
Integration tests fail due to missing UV virtual environment setup可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭
难度 2/5 1-3 小时 新手友好度 65/100
PolicyEngine/policyengine-sim-api#314 ·
维护者通常 1 天内回复
-
Daily dependency update fails: merging main into the update branch produces a uv.lock that uv cannot parse可能已有人在做 @anth-volk 于 1 天前认领。 未关闭
难度 4/5 3-5 天 新手友好度 25/100
PolicyEngine/policyengine-sim-api#889 ·
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 35/100
PolicyEngine/policyengine-sim-api#884 ·
维护者通常 1 天内回复
-
Update policyengine to 6.10.0可能已有人在做 @policyengine 于 1 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 35/100
PolicyEngine/policyengine-sim-api#882 ·
维护者通常 1 天内回复
查看 PolicyEngine/policyengine-sim-api 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 72/100
CLIMADA-project/climada_python#1337 ·
维护者通常 3 天内回复
-
难度 2/5 1-3 小时 新手友好度 68/100
8go/matrix-commander#233 ·
-
documentation
难度 2/5 1-3 小时 新手友好度 66/100
-
documentation enhancement priority:high size:M
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 1 天内回复
-
Validate non-divisible effective batch sizes in the Unsloth LoRA backend可能已有人在做 @debesh-biswas 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 70/100