fix(ci): wait-for-deploy refetches missing trees, skips gate if unresolvable #101

Merged

nrupard merged 1 commit from fix/e2e-wait-deploy-skip-when-unresolvable into main

2026-06-05 17:39:50 +02:00

nrupard commented

2026-06-05 17:39:10 +02:00

Owner

Summary

Post-merge E2E run on 6bf0e9a (the unshallow-fallback PR's merge commit) still hit:

Could not resolve build-trigger SHA: Error: No commit at-or-before 6bf0e9a... touches any build-trigger path (clone depth=370, shallow=false).

Clone depth was 370 and the shallow check returned false, but the path-filtered git log still returned empty. Forgejo's actions/checkout applies an object filter (--filter=blob:none / --filter=tree:0) that strips the tree objects git log -- <path> needs to test path membership; the query then silently returns zero matches even though the commits are present.

Fix

Two changes to wait-for-deploy.mjs:

New tryRefetch() step runs git fetch --refetch origin to repopulate the missing tree objects. Resolver now tries: initial query → unshallow if shallow → refetch → retry.
Skip the gate when unresolvable (instead of failing or falling back to GITHUB_SHA). Falling back to GITHUB_SHA on a doc/test-only commit re-creates the original problem (polling 10m on a SHA staging never serves). Phase 1 of PMS-140 is informational, not a merge gate, so the right failure mode is "tests proceed, operator sees warning, follow up out-of-band" - not "block CI on a runner-side issue".

Test plan

Merge to main; the next E2E run either resolves a real build-trigger SHA (refetch succeeded) or prints the SKIP-gate warning block and proceeds to the test phase. Either outcome means the job stops being a SHA-resolution dead-end.

## Summary Post-merge E2E run on `6bf0e9a` (the unshallow-fallback PR's merge commit) still hit: > Could not resolve build-trigger SHA: Error: No commit at-or-before 6bf0e9a... touches any build-trigger path (clone depth=370, shallow=false). Clone depth was 370 and the shallow check returned false, but the path-filtered `git log` still returned empty. Forgejo's `actions/checkout` applies an object filter (`--filter=blob:none` / `--filter=tree:0`) that strips the tree objects `git log -- <path>` needs to test path membership; the query then silently returns zero matches even though the commits are present. ## Fix Two changes to `wait-for-deploy.mjs`: 1. **New `tryRefetch()` step** runs `git fetch --refetch origin` to repopulate the missing tree objects. Resolver now tries: initial query → unshallow if shallow → refetch → retry. 2. **Skip the gate when unresolvable** (instead of failing or falling back to `GITHUB_SHA`). Falling back to `GITHUB_SHA` on a doc/test-only commit re-creates the original problem (polling 10m on a SHA staging never serves). Phase 1 of PMS-140 is informational, not a merge gate, so the right failure mode is "tests proceed, operator sees warning, follow up out-of-band" - not "block CI on a runner-side issue". ## Test plan - [ ] Merge to main; the next E2E run either resolves a real build-trigger SHA (refetch succeeded) or prints the SKIP-gate warning block and proceeds to the test phase. Either outcome means the job stops being a SHA-resolution dead-end.

nrupard added 1 commit

2026-06-05 17:39:10 +02:00

fix(ci): wait-for-deploy refetches missing trees, skips gate if unresolvable

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

Details

Check / fmt + clippy + compile + tests (pull_request) Successful in 1m26s

Details

9c73dd158b

The post-merge run on 6bf0e9a reported clone depth=370, shallow=false, yet `git log -1 -- src crates ...` still returned empty. Forgejo's actions/checkout applies an object filter (`--filter=blob:none` / `--filter=tree:0`) that strips the tree objects `git log -- <path>` needs to test path membership; the query then silently returns zero matches even though the commits are present.

Two changes:

1. Add a `tryRefetch()` self-heal step that runs `git fetch --refetch origin` to repopulate the missing tree objects. The resolver now tries: initial query -> unshallow if shallow -> refetch -> final query. Either heal succeeding short-circuits.

2. On a definitive miss after all heals, SKIP the deploy-sync gate with a loud warning instead of failing the job or falling back to GITHUB_SHA. Falling back to GITHUB_SHA on a doc/test-only commit re-creates the very problem the gate exists to avoid (polling 10m on a SHA staging never serves). Phase 1 of PMS-140 is informational, not a merge gate, so the right failure mode is "tests proceed, operator sees a warning, follow up out-of-band" - not "block CI on a runner-side issue".

#PMS-140