Tags: pullfrog/pullfrog
Tags
no-key error: name a subscription the runner could not install (#1452) a sudo-less self-hosted runner skips its Codex or Grok subscription (#1442), and a run that needs it then reports no key. the generic copy told the owner to add an OPENAI_API_KEY; it now says the subscription is stored and names the real remedies: passwordless sudo, a GitHub-hosted runner, or an API key.
Replace the vendored `yes` with the npm package `yes@0.0.3` (#1450)
* Replace the vendored `yes` with the npm package `yes@0.0.1`
`action/yes/` held a private copy of the retry / cache / in-flight-dedup
primitive. That code now lives in its own repo (colinhacks/yes) and is
published to npm as `yes@0.0.1` under the `next` dist-tag. (`latest` is
an unrelated old CLI at 1.1.1, so the pin is the exact version.) This
commit moves Pullfrog onto the package:
- `action/yes/index.ts` is now `export * from "yes"`. The vendored
`standard-schema.ts` and README are deleted. The file still exists so
that the public `pullfrog/yes` subpath (package.json exports, esbuild
entry, tsconfig.exports, the Turbopack alias in next.config.ts) and
the relative `../yes/index.ts` imports inside `action/` keep working
unchanged.
- `yes` is an `action/` devDependency, like every other action dep. The
esbuild config bundles all dependencies into `dist/`, so the published
`pullfrog` needs no runtime dependency on it. `dist/yes/index.d.ts`
now re-exports from "yes", the same as the existing `.d.ts` files that
already reference devDependencies such as `@octokit/rest` and `zod`.
`lru-cache`, `object-hash` and `@types/object-hash` leave `action/`'s
devDependencies: the vendored copy was their only consumer, and `yes`
brings them as its own dependencies. Both lockfiles are updated
(`pnpm-lock.yaml` for the workspace, `action/pnpm-lock.yaml` for the
standalone `pullfrog/pullfrog` sync).
- `yes@0.0.1` is added to `minimumReleaseAgeExclude` in both
`pnpm-workspace.yaml` files. It was published today, and the 24h
release-age gate refuses it otherwise. This follows the exact-version
exclude precedent of the codex pins.
The option `bail` is renamed `rethrow` in the package, with the same
semantics: it runs for every thrown error, and `true` rethrows that
error at once instead of retrying. All 49 `bail` option keys passed to
`yes.op` across `utils/`, `action/` and `test/yes.test.ts` become
`rethrow:`. The helper function `utils/bail.ts#bail` keeps its name,
because it is a classifier passed as the value (`rethrow: bail`) and
renaming it would churn about 20 imports for no change in meaning.
Comments that name the option, plus AGENTS.md and the wiki (`yes.md`,
`README.md`, `modes.md`, `prisma-retry.md`), are updated to match.
Behavioural differences between the vendored copy and yes@0.0.1:
- Schema failures throw `yes.ValidationError` (which carries `.issues`)
instead of a plain Error, and they are never retried. Previously an
input or output validation failure ran inside the retry loop and was
retried. The message format "validation failed: ..." is unchanged.
- Input is validated once, before the cache key is derived. The key,
the in-flight dedup and what `.invalidate` sees are therefore the
validated value, not the raw input. `.clear`/`.has` normalize a key
through the schema when it validates synchronously. No Pullfrog op
uses an `input` schema, so this is inert here today.
- The context (second argument) is always forwarded. Previously it was
forwarded only when `fn.length === 2`, so a default-valued or rest
`ctx` was silently dropped. The wiki trap documenting that is removed.
- Everything else matches, including the GitHub GraphQL fallback in
`retryAfterMs` (top-level `error.headers` on a `GraphqlResponseError`,
from #1435), which was ported upstream before 0.0.1 was published.
The package also ships a `yes` bin (kept from the old CLI) that lands
in `action/node_modules/.bin` and shadows coreutils `yes` for package
scripts. `action/utils/subprocess.test.ts` pipes `yes | head`, and an
early build of the bin hung there. 0.0.1 ships a coreutils-compatible
bin that exits on EPIPE, and the test passes unchanged.
Checks: skill check, typecheck, lint, format, action tests (924 passed,
7 skipped), root tests (1035 passed, 7 skipped), `pullfrog` build and
`next build` are all green against yes@0.0.1 resolved from npm.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* Stop the subprocess tail-cap test from running the `yes` bin
The earlier commit assumed yes@0.0.1's coreutils-compatible bin would
leave this test alone. It does not under load. The `yes` npm package
installs a node `yes` bin into `action/node_modules/.bin`, and package
scripts put that ahead of coreutils on PATH. In
`yes ABCDEFGH | head -c 2097152 1>&2`, the node process inherits fd 2,
which is the same pipe as head's stdout after `1>&2`. Node sets its
stdio pipes to O_NONBLOCK. That flag lives on the shared open file
description, so head inherits it. When the wrapper's reader falls
behind, head gets EAGAIN ("error writing 'standard output': Resource
temporarily unavailable") and exits 1.
This passed in isolation but failed the husky pre-push suite twice in
a row. The test only needs ~2 MiB of stderr, so it now generates the
bytes from /dev/zero and never names `yes`.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* Pin `yes` to 0.0.3
0.0.3 (colinhacks/yes f9f13d8, dist-tag `next`) supersedes 0.0.1.
The library code Pullfrog uses is the same: `rethrow`,
`ValidationError`, and the GraphQL `error.headers` fallback in
`retryAfterMs`. The difference is the bin. 0.0.3 ships the original
1.1.1 `yes` CLI byte for byte, which was kept by agreement with the
npm name's previous owner. It is a node script, still lands in
`action/node_modules/.bin`, and still shadows coreutils `yes` on
package-script PATH. It is also not coreutils-compatible: it prints
only the first argument and ends lines with CRLF. So the
`subprocess.test.ts` rewrite stays.
The release-age excludes in both `pnpm-workspace.yaml` files move to
the exact new version. Both lockfiles resolve `yes@0.0.3` from the
registry.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
PreviousNext