fix(ci): resolve deploy-sync expected SHA to the last build-relevant commit

nrupard commented

2026-06-05 17:31:31 +02:00

Owner

build-oci-image.yml only fires when one of a fixed set of paths changes (src/, crates/, migrations/, .cargo/, Cargo.toml, Cargo.lock, oci-build/, the build workflow itself). A merge to main that touches only docs/tests/CI never republishes :latest, so staging keeps serving the previous build and the E2E deploy-sync gate polls forever for a SHA staging can never report.

Walk git log from GITHUB_SHA backwards in wait-for-deploy.mjs and find the most recent commit that touched any build-trigger path; poll for THAT hash. When the head commit is build-relevant the resolved SHA equals GITHUB_SHA, so build-publishing merges still gate on themselves; when the head is doc/test/CI-only, the gate matches the image that staging is actually running.

BUILD_TRIGGER_PATHS is hardcoded with a pointer comment to build-oci-image.yml's on.push.paths so future drift between the two is at least catchable in code review.

Restore fetch-depth: 0 on actions/checkout for the e2e job - the git log walk needs more than depth 1. The earlier "drop fetch-depth: 0" change is reverted; the gain was negligible and it broke this gate.

#PMS-140

build-oci-image.yml only fires when one of a fixed set of paths changes (src/, crates/, migrations/, .cargo/, Cargo.toml, Cargo.lock, oci-build/, the build workflow itself). A merge to main that touches only docs/tests/CI never republishes :latest, so staging keeps serving the previous build and the E2E deploy-sync gate polls forever for a SHA staging can never report. Walk `git log` from GITHUB_SHA backwards in wait-for-deploy.mjs and find the most recent commit that touched any build-trigger path; poll for THAT hash. When the head commit is build-relevant the resolved SHA equals GITHUB_SHA, so build-publishing merges still gate on themselves; when the head is doc/test/CI-only, the gate matches the image that staging is actually running. BUILD_TRIGGER_PATHS is hardcoded with a pointer comment to build-oci-image.yml's `on.push.paths` so future drift between the two is at least catchable in code review. Restore `fetch-depth: 0` on actions/checkout for the e2e job - the git log walk needs more than depth 1. The earlier "drop fetch-depth: 0" change is reverted; the gain was negligible and it broke this gate. #PMS-140

nrupard added 1 commit

2026-06-05 17:31:31 +02:00

fix(ci): resolve deploy-sync expected SHA to the last build-relevant commit

Create release / Create release from merged PR (pull_request) Has been skipped

Details

Check / fmt + clippy + compile + tests (pull_request) Successful in 2m10s

Details

6040838a55

build-oci-image.yml only fires when one of a fixed set of paths changes (src/, crates/, migrations/, .cargo/, Cargo.toml, Cargo.lock, oci-build/, the build workflow itself). A merge to main that touches only docs/tests/CI never republishes :latest, so staging keeps serving the previous build and the E2E deploy-sync gate polls forever for a SHA staging can never report.

Walk `git log` from GITHUB_SHA backwards in wait-for-deploy.mjs and find the most recent commit that touched any build-trigger path; poll for THAT hash. When the head commit is build-relevant the resolved SHA equals GITHUB_SHA, so build-publishing merges still gate on themselves; when the head is doc/test/CI-only, the gate matches the image that staging is actually running.

BUILD_TRIGGER_PATHS is hardcoded with a pointer comment to build-oci-image.yml's `on.push.paths` so future drift between the two is at least catchable in code review.

Restore `fetch-depth: 0` on actions/checkout for the e2e job - the git log walk needs more than depth 1. The earlier "drop fetch-depth: 0" change is reverted; the gain was negligible and it broke this gate.

#PMS-140