ci: fold parity into QA release validation#74622
Conversation
09c35a9 to
228a2c2
Compare
|
/clawsweeper automerge |
|
Codex review: passed. Summary Reproducibility: not applicable. as a CI/docs refactor. The high-confidence review path is static comparison of the repaired PR diff against current workflow/docs code plus exact-head check status. Next step before merge Security Review detailsBest possible solution: Land the repaired consolidation through the automerge path once exact-head checks and branch protection pass, keeping parity coverage in QA-Lab and release-validation entrypoints. Do we have a high-confidence way to reproduce the issue? Not applicable as a CI/docs refactor. The high-confidence review path is static comparison of the repaired PR diff against current workflow/docs code plus exact-head check status. Is this the best way to solve the issue? Yes, after the repair. The patch removes duplicated standalone parity workflow routing while preserving QA parity in existing QA/release validation and aligning the Docker guard with current package-backed live lanes. What I checked:
Likely related people:
Remaining risk / open question:
Codex review notes: model gpt-5.5, reasoning high; reviewed against 9eb79bcf997b. |
|
🦞🦞
Draft PRs stay fix-only until GitHub marks them ready for review. Pause with Automerge progress:
|
228a2c2 to
3482654
Compare
Summary: - The PR deletes the standalone `Parity gate` workflow, renames QA parity wording from gate to lane, routes docs toward QA/release validation, and adjusts the Docker E2E boundary guard for package-backed live lanes. - Reproducibility: not applicable. as a CI/docs refactor. The high-confidence review path is static comparison of the repaired PR diff against current workflow/docs code plus exact-head check status. ClawSweeper fixups: - Included follow-up commit: ci: fold parity into QA release validation - Ran the ClawSweeper repair loop before final review. Validation: - ClawSweeper review passed for head 3482654. - Required merge gates passed before the squash merge. Prepared head SHA: 3482654 Review: openclaw#74622 (comment) Co-authored-by: Vincent Koc <vincentkoc@ieee.org> Co-authored-by: clawsweeper <274271284+clawsweeper[bot]@users.noreply.github.com>
Summary: - The PR deletes the standalone `Parity gate` workflow, renames QA parity wording from gate to lane, routes docs toward QA/release validation, and adjusts the Docker E2E boundary guard for package-backed live lanes. - Reproducibility: not applicable. as a CI/docs refactor. The high-confidence review path is static comparison of the repaired PR diff against current workflow/docs code plus exact-head check status. ClawSweeper fixups: - Included follow-up commit: ci: fold parity into QA release validation - Ran the ClawSweeper repair loop before final review. Validation: - ClawSweeper review passed for head 3482654. - Required merge gates passed before the squash merge. Prepared head SHA: 3482654 Review: openclaw#74622 (comment) Co-authored-by: Vincent Koc <vincentkoc@ieee.org> Co-authored-by: clawsweeper <274271284+clawsweeper[bot]@users.noreply.github.com>
…approval-turn-tool-followthrough timeouts Carries forward the surface-bump portion of #74290 (closed in favor of this slim follow-up since the parity-gate.yml workflow file the original PR also touched was retired by #74622 'ci: fold parity into QA release validation'). The mock-openai parity lanes that now live in `openclaw-release-checks.yml` and `qa-live-transports-convex.yml` were still pinned to `anthropic/claude-opus-4-6` / `anthropic/claude-sonnet-4-6` for the baseline and `openai/gpt-5.4-alt` for the candidate alt model. That left the parity baseline one model-generation behind the active Opus 4.7 / GPT-5.5 defaults already used elsewhere on main (CHANGELOG.md:803, docs/providers/anthropic.md:108, openclaw-live-and-e2e-checks-reusable.yml:1894). The `approval-turn-tool-followthrough` scenario was using 20s/30s `liveTurnTimeoutMs` fallbacks that timed out on cold mock-gateway parity runs (the deleted `parity-gate.yml` env-var comments described exactly this scenario flake). Bumping all four turn fallbacks to 60s matches what the mock provider's `resolveTurnTimeoutMs` returns for fallbackMs (it returns the fallback unchanged) so cold starts have breathing room before the approval/follow-through chain has to complete. This PR does NOT touch: - The retired `.github/workflows/parity-gate.yml` (deleted on main by #74622) - Internal artifact directory names `gpt54`/`opus46` (cosmetic, out of scope for a slim follow-up) - The Discord QA scenario lane and the release-validation lane that intentionally pin `openai/gpt-5.4` (separate concerns) Refs #74290.
…approval-turn-tool-followthrough timeouts Carries forward the surface-bump portion of #74290 (closed in favor of this slim follow-up since the parity-gate.yml workflow file the original PR also touched was retired by #74622 'ci: fold parity into QA release validation'). The mock-openai parity lanes that now live in `openclaw-release-checks.yml` and `qa-live-transports-convex.yml` were still pinned to `anthropic/claude-opus-4-6` / `anthropic/claude-sonnet-4-6` for the baseline and `openai/gpt-5.4-alt` for the candidate alt model. That left the parity baseline one model-generation behind the active Opus 4.7 / GPT-5.5 defaults already used elsewhere on main (CHANGELOG.md:803, docs/providers/anthropic.md:108, openclaw-live-and-e2e-checks-reusable.yml:1894). The `approval-turn-tool-followthrough` scenario was using 20s/30s `liveTurnTimeoutMs` fallbacks that timed out on cold mock-gateway parity runs (the deleted `parity-gate.yml` env-var comments described exactly this scenario flake). Bumping all four turn fallbacks to 60s matches what the mock provider's `resolveTurnTimeoutMs` returns for fallbackMs (it returns the fallback unchanged) so cold starts have breathing room before the approval/follow-through chain has to complete. This PR does NOT touch: - The retired `.github/workflows/parity-gate.yml` (deleted on main by #74622) - Internal artifact directory names `gpt54`/`opus46` (cosmetic, out of scope for a slim follow-up) - The Discord QA scenario lane and the release-validation lane that intentionally pin `openai/gpt-5.4` (separate concerns) Refs #74290.
Summary
Parity gateworkflow entirelyQA-Lab - All Lanesmock parity lane and release-checks QA parity groupFull Release Validationwithrerun_group=qa-parity/ release-checks QA coverage instead of PR landing CITesting