[PavelMakarchuk]

Fixes #4083

Summary

• New script .github/scripts/resolve_policyengine_live_since.sh: reads the .py version from uv.lock, and the DEPLOYED_POLICYENGINE_VERSION and POLICYENGINE_VERSION_LIVE_SINCE of the revision serving 100% of traffic (steps.previous.outputs.revision). Same version → keeps that date; a new version or a first deploy → the deploy time; a revision without a recorded date (deployed before this change) or a failed gcloud lookup → empty, i.e. unknown, rather than a later, wrong date. A failed lookup never fails the deploy.
• deploy_cloud_run_candidate.sh adds both values to the candidate's environment; push.yml passes PREVIOUS_CLOUD_RUN_REVISION to the staging and production deploy steps (single-line run: unchanged).
• GET /deployment (next to /health) returns policyengine_version (installed), policyengine_version_live_since and revision (K_REVISION). The date stays null after merge until the next .py version is deployed, because the version now live started before dates were recorded.

Why not a deploy timestamp: the API deploys several times a day while .py stays the same, so "last deployed" is nearly always today. The app-v2 Deployments developer tool (PolicyEngine/policyengine-app-v2#1450) will read /deployment for its "Live since" column; the household API already reports the equivalent.

Note: the date is the candidate deploy time; traffic moves to the candidate after its smoke checks, minutes later.

Testing

• tests/unit/test_policyengine_live_since.py (10 tests): same version keeps the date; a new version and a first deploy get the deploy time; a revision without a date (with or without a recorded version) and a failed gcloud give an empty date; a lock without policyengine fails; the dry-run candidate deploy sets both variables; /deployment returns the fields and a null date without the variable.
• tests/unit/test_cloud_run_candidate_deploy.py, test_cloud_run_push_workflow.py, test_asgi_factory.py: 78 passed.
• ruff format, ruff check on changed files; shellcheck -x on both scripts; python scripts/run_quality_guards.py: all passed.

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 87.84%. Comparing base (3fde3da) to head (7cd3e9e).
⚠️ Report is 1 commits behind head on master.

Additional details and impacted files

@@             Coverage Diff             @@
##           master    #4084       +/-   ##
===========================================
+ Coverage   50.82%   87.84%   +37.02%     
===========================================
  Files         254      270       +16     
  Lines       14635    16070     +1435     
  Branches     2339     2627      +288     
===========================================
+ Hits         7438    14117     +6679     
+ Misses       6570     1284     -5286     
- Partials      627      669       +42     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[anth-volk]

Code-quality notes from a review of this PR; four inline comments below.

Environment variables, traced from where each value comes from to where it is used:

Variable	Provided by	How it reaches the code
PREVIOUS_CLOUD_RUN_REVISION	revision output of the "Capture current Cloud Run … state" step (gcloud run services describe)	Step-level env: on the staging and production candidate deploy steps
CLOUD_RUN_PROJECT, CLOUD_RUN_REGION	Defaults in cloud_run_set_defaults	The new script sources cloud_run_env.sh itself
DEPLOYED_POLICYENGINE_VERSION, POLICYENGINE_VERSION_LIVE_SINCE	Output of resolve_policyengine_live_since.sh	Added to --set-env-vars of gcloud run deploy; read back from .spec.containers[0].env, which is correct for this single-container service
K_REVISION	Set by Cloud Run at runtime	Not configured in the repository
GCLOUD_BIN, POLICYENGINE_LOCK_FILE, POLICYENGINE_LIVE_SINCE_NOW, CLOUD_RUN_DRY_RUN	Test overrides	Not set in the workflows, so the defaults apply

One thing I couldn't confirm from the repository: whether the deploy service account (GCP_DEPLOY_SERVICE_ACCOUNT) has run.revisions.get. If it doesn't, gcloud run revisions describe fails and the date is silently empty on every deploy instead of failing the deploy.

[PavelMakarchuk]

@anth-volk thanks — all four inline points are addressed in 7cd3e9e (replies inline).

On run.revisions.get: the deploy account already needs it. The same staging and production deploy jobs run gcloud run revisions describe in resolve_cloud_run_candidate_state.sh and set_cloud_run_revision.sh, so the new script needs no new permission. If the call failed anyway, the date is left empty (unknown) and the deploy continues.

Also merged current master into the branch. Ready for another look.

[anth-volk]

Thanks, all four points are addressed in 7cd3e9e, and you're right about run.revisions.get: the same deploy jobs already run gcloud run revisions describe in resolve_cloud_run_candidate_state.sh and set_cloud_run_revision.sh.

One minor, optional point: a lock without policyengine now fails with the relock's message ("…so the packages its extras pin can't be held back"), which reads oddly during a deploy, and the script's own "policyengine is not locked" check can no longer run, because set -e exits as soon as locked_packages.py fails.