mirror of
https://github.com/openclaw/openclaw.git
synced 2026-07-22 10:51:11 +00:00
96b2a203ce
* perf(pr): accept gate-proven in-progress CI runs for landing verify-pr-hosted-gates required the whole CI run to reach completed, but openclaw/ci-gate — the branch-protection check — needs every selected lane and fails on any non-success, so a successful gate bound to the run's check suite proves the merge-relevant outcome while post-gate stragglers (timing summaries, artifact uploads) are still running. prepare-run now accepts an in-progress run whose own gate check succeeded, cutting one to several minutes per landing. Exact attempt binding via check_suite id prevents a stale gate from a previous attempt vouching for a rerun; gate proof only applies to the exact head under verification, never recent-parent evidence. * fix(pr): bind gate proof to the run attempt, not the check suite Autoreview P1: check suites survive reruns, so a prior attempt's successful gate could vouch for an in-progress rerun that has not reached its own gate. The proof now goes through the attempt-scoped jobs listing (filter=latest): the gate job must carry the run's own run_attempt. Regression tests cover same-run/previous-attempt, different-run, failed, and missing gate jobs. * fix(pr): rely on filter=latest for gate attempt scoping Autoreview P2: the REST list-jobs payload does not expose run_attempt, so requiring it rejected every genuine rerun gate. loadCiGateJobs already fetches per run with filter=latest, which scopes to the current attempt, so a run_id match binds the gate correctly without the absent field. * fix(pr): declare ciGateJobs in the hosted-gates evidence typedef * fix(pr): un-export the internal gate helper and loosen test id typing hasSuccessfulCiGateJob is only reached through collectHostedGateEvidence, so exporting it tripped the hard-zero deadcode gate; the new test also typed workflow ids as number against the unknown-shaped return. * fix(pr): bind early gate proof to the run attempt Autoreview P1: workflow attempts share a run id and filter=latest keeps a not-yet-rerun job's prior-attempt execution, so a partial rerun could surface an old successful ci-gate. The REST job payload does expose run_attempt (verified live), so fetch the attempt-specific jobs endpoint and require the gate job's run_attempt to equal the run's. * fix(pr): revalidate the run attempt after loading gate jobs Autoreview P2: a rerun starting between the workflow-run snapshot and the attempt-specific jobs fetch could return a stale prior-attempt gate. Re-read the run after fetching its jobs and drop the evidence if the run completed or its attempt advanced, so early proof only applies while the same attempt is still pending.