Tags: pullfrog/pullfrog
Tags
models: Grok 4.3 as the xAI Smart ladder's cheap rung, and a ladder m… …ust reach two models (#1352) the xai ladder's cheap rung was grok-fast, a retired alias whose fallback is grok, so every tier ran Grok 4.6 at full price and the console listed two rows both named Grok. grok-4.3 (1.25/2.5, cache-read 0.2 vs 4.6's 2/6, 0.5) is the only live xAI model a rung can save on; the module-load check now also refuses a ladder whose rungs collapse to one terminal alias. action 0.1.77 -> 0.1.78.
release: wait npm's review hold out instead of failing the release on it npm holds a new version in automated review before the registry serves it. the version does not exist until that clears, and the hold is not a propagation cache: measured 3.5min on 0.1.70, ~54min on 0.1.71, 236min on 0.1.72. the wait budget was 10 minutes, so it expired on two releases running and left v0 pinned two versions behind for 19 hours while the CLI it should have pointed at was already on npm. three changes, all mirroring what zod's release.yml already does against the same npm behavior (it measured 16/25/116min and waits 240): - publish step is continue-on-error. a re-run against a version already in review dies on E409, which is not a lost publish — it means the first attempt is in flight. registry liveness is the only gate that decides whether the release moves. - every registry read goes to registry.npmjs.org directly. npm view revalidates a cached packument and reports a live version as missing, which is what made a slow read indistinguishable from a stalled one. - the wait runs 330min inside a 360min job cap, up from 10min. the repo is public, so an idle runner is free, and a release that completes itself beats one that needs someone awake to re-run it. the skill loses its 10-minute-poll guidance and gains the measurements, plus a warning not to gh run watch a job that legitimately runs for hours.
Float the action's post step instead of nagging SHA-pinned repos (#1329) * Float the action's post step instead of nagging SHA-pinned repos The PR footer carried a warning on every review telling repos pinned to a commit SHA to switch to `@v0` or add Dependabot. It was aimed at the wrong reader (the PR author rarely wrote the workflow file), it advised undoing a hardening GitHub itself recommends, and it existed to paper over an asymmetry that was ours. `entry.ts` bootstraps: it resolves `pullfrog@^<version>` from npm and runs the real agent from there, so the agent floats regardless of the `uses:` pin. `entryPost.ts` did not — it carried the cleanup logic inline, plus stdlib-only re-implementations of `@actions/core` and `apiFetch`, because #815's `ERR_MODULE_NOT_FOUND` outage made a bare specifier there unsafe. That fix worked and froze ~312 lines at whatever commit a consumer pinned. The freeze was live. Across Aug+Sep run logs, SHA-pinned runs logged `codex post-hook:` 133 times and `oauth post-hook:` zero times, while `@v0` logged both — every SHA-pinned repo was still running pre-#1275 cleanup code and would never have received the xAI write-back branch. So `entryPost.ts` becomes a bootstrap like `entry.ts`, and the logic moves to `utils/oauthWriteback.ts` behind `gha --post`. #815's objection was npm latency on every cleanup; the state gate answers it — the harnesses only save `oauth_writeback` when a credential could rotate, and 3,422 of 3,861 post-hook log lines in the corpus rotate nothing, so those runs read one env var and spawn nothing. With the post step floating, a SHA pin freezes nothing the main step does not already freeze, so the warning is no longer true and comes out entirely, along with `shaPinned` and the log annotation. - entryPost.ts is ~10 lines; the stdlib-only invariant still holds and its import-graph test still guards it (runCli.ts is stdlib-only too) - gha's run() routes --post around core.setFailed: the agent has already exited, so a non-zero exit there is #815's shape - delete utils/ghaCore.ts and utils/postApiFetch.ts, now that the real @actions/core and apiFetch are reachable - docs/versioning.mdx drops the freeze warning - new wiki/action-bootstrap.md records why both entrypoints stay thin Refs #815 * Route the harnesses through the shared writeback state constant `oauth_writeback` was spelled as a bare literal in both harnesses; a typo in either silently disables the write-back rather than failing. They can import the constant freely — only entryPost.ts cannot, since that would drag @actions/core into the frozen stdlib-only graph. Documented on the constant so the remaining duplication reads as deliberate. Also corrects the AGENTS.md post-hook pointer, which this branch made stale. * Trim the post-entrypoint header and record the release-window finding The header duplicated what wiki/action-bootstrap.md now carries; it keeps only the two rules that bind anyone editing the file, and points at the wiki. Adds the release-window note: a publish moves npm and the action checkout at slightly different moments, so a new entryPost.ts can bootstrap an older published CLI that rejects `--post`. Verified against the real published package — the child exits 1, swallowErrors catches it, entryPost exits 0. * Tighten the wiki's entrypoint sentence to match the state gate * Keep the skip log line in the post step Copilot caught that gating on the state made the no-op path silent. That log line is the only evidence the hook ran at all: without it, a gate that stops matching — a renamed state key, say — is indistinguishable from a run that legitimately had nothing to persist, and it surfaces days later as a dead Codex chain rather than at the moment of the bug. It is also the signal the fleet measurement in the wiki is counted from. Also corrects the wiki's cost paragraph, which read as though the post step loads from npm on every cleanup. * Correct the versioning docs to describe where the cleanup code comes from
PreviousNext