mirror of
https://github.com/CopilotKit/CopilotKit.git
synced 2026-09-14 16:26:20 +08:00
Jordan Ritter
7908788a71
The PR bumps copilotkit==0.1.91 -> 0.1.92 across three showcase requirements.txt files (langgraph-python, langgraph-fastapi, strands). The validate-pins ratchet compares the SHA-256 of the sorted [FAIL] tuple set against the recorded baseline. The langgraph-fastapi tuple "copilotkit pinned ==0.1.91, Dojo has ==0.1.87" now reads "==0.1.92, Dojo has ==0.1.87" — same already-failing tuple, new text, so the FAIL count is unchanged at 106 but the hash flipped. No new pin drift was introduced (count stays at 106). The pre-existing langgraph-fastapi <-> Dojo parity gap is out of scope for this bump and tracked separately. Updating only validatePinsFailHash to reflect the new tuple text. Old: d340cdebe623177b957b62576821b51cde7f174b6b788040d67cc87e3d20b702 New: 4355457a222f8011c361da7a848d7361e897ee588ad0b8c6487b851fd0c23b77
7 lines
1005 B
JSON
7 lines
1005 B
JSON
{
|
|
"_comment": "Drift ratchet baseline for showcase_validate.yml. `validatePinsFailCount` holds the last-known FAIL count; `validatePinsFailHash` is a SHA-256 of the sorted, deduplicated `[FAIL] ...` lines from validate-pins.ts. CI compares BOTH: if the count changes, it tells you to ratchet (up rejected, down instructed). If the count is equal but the hash differs, the FAIL *set* has drifted (one item fixed, another regressed) and CI fails with a diff. Never raise the count without an explicit review + sign-off. `baselineDemoCount` is the per-package e2e-spec-count floor (single source of truth consumed by both the workflow and validate-parity.ts). NOTE: validate-parity.ts `BASELINE_DEMO_COUNT` default must match `baselineDemoCount` here; keep them in sync. See .github/workflows/showcase_validate.yml 'Run validate-pins (ratchet)' step.",
|
|
"validatePinsFailCount": 106,
|
|
"validatePinsFailHash": "4355457a222f8011c361da7a848d7361e897ee588ad0b8c6487b851fd0c23b77",
|
|
"baselineDemoCount": 9
|
|
}
|