Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Staging deployments do not promote their tested Simulation Entrypoint revision

オープン
#893 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@anth-volk がすでに取り組んでいます。

2026年10月21日 から。

  • #894 @anth-volk による — オープン

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
35/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
停滞
技術スタック
docker, github-actions, python
領域
ci-cd, cloud, devops

調査の方向性

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時間
マージ済み PR(30日)
60

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

PolicyEngine/policyengine-sim-api のほかの issue

PolicyEngine/policyengine-sim-api の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。