feat(ci): selective preview publish via targets input

[abcxff]

No description provided.

[abcxff]

Stack for rivet-dev/actors

• #5629 feat(ci): selective preview publish via targets input 👈
• main

Get stack: forklift get 5629
Push local edits: forklift submit
Merge when ready: forklift merge 5629

_{change ozmvkswy}

[railway-app]

🚅 Deployed to the actors-pr-5629 environment in rivet-frontend

Service	Status	Web	Updated (UTC)
website	🕐 Queued (View Logs)	Web	Sep 1, 2026 at 11:04 pm
frontend-inspector	😴 Sleeping (View Logs)	Web	Sep 1, 2026 at 8:44 pm
kitchen-sink	😴 Sleeping (View Logs)	Web	Sep 1, 2026 at 8:43 pm
frontend-cloud	😴 Sleeping (View Logs)	Web	Sep 1, 2026 at 8:42 pm
mcp-hub	✅ Success (View Logs)	Web	Sep 1, 2026 at 8:36 pm
ladle	✅ Success (View Logs)	Web	Sep 1, 2026 at 8:36 pm

[claude]

Review

Reviewed the selective preview-publish scoping (targets input → scope.ts → gated matrix/jobs/npm publish). The design is solid: scope.ts centralizes the group→build-target/npm-family mapping, releases are hard-rejected from using a partial targets value, and the out-of-scope-dependency pinning in bumpPackageJsons (version.ts:206-219) is a nice touch that keeps a rivetkit-only preview installable without republishing @rivetkit/engine-cli. I traced through all four target groups (including the container-runner-only case, where scopedFamilies correctly yields an empty family Set and publishAll/assertDiscoverySanity gracefully publish zero npm packages since container-runner has no npm family) and didn't find a correctness bug in the scoping logic itself.

A few smaller things worth a look:

1. .github/workflows/publish.yaml — Rust crate dry-run isn't scope-gated. "Dry-run Rust crate publish" (and the release "Publish Rust crates" step) run on every non-release trigger regardless of targets, so a container-runner-only or cli-only preview still pays for a cargo publish --dry-run of rivet-error-macros. Doesn't break anything, but it's slightly at odds with the PR's stated goal of skipping unrelated builds for a narrowed target — might be worth gating on contains(needs.context.outputs.targets, 'rivetkit') too (Rust crates are effectively part of the rivetkit family) if that step is non-trivial cost-wise.

2. Inconsistent if: gating style on the three "Place … binaries" steps. Place engine binaries in engine-cli platform packages, Place CLI binaries in CLI platform packages, and Place bundled engine in CLI platform packages have no if: condition at all, unlike their sibling Download … artifacts steps. They're safe today only because of the [ -e "$f" ] || continue guard against the unmatched glob, but it's a bit fragile/inconsistent with the rest of the file's explicit gating. Consider adding matching if: contains(needs.context.outputs.targets, '...') conditions for clarity.

3. contains() substring matching for scope gates is a bit fragile long-term. Several steps gate on contains(needs.context.outputs.targets, 'cli') / 'engine' / 'rivetkit' (plain substring match on a comma-joined string), whereas the build job's own gate uses a space-wrapped exact-match case pattern specifically to avoid substring false-positives. Today none of the four group names collide as substrings of each other, so it works, but it'd be safer/more consistent to reuse the same exact-match idiom everywhere these scope checks appear, so a future target name addition can't silently start matching the wrong steps.

4. Bootstrapping edge case in resolveLatestPublished (version.ts:155-167). If an out-of-scope dependency has never been published before (e.g., the very first run that narrows scope before a full/all-target run has ever published @rivetkit/engine-cli), npm view <dep> version returns nothing and the bump throws. Not a bug given this repo's packages are already published, but worth keeping in mind if a new target group/package family is introduced later — the first selective run excluding it will fail until at least one full run publishes it.

5. No test coverage for the new scope-resolution logic. parseTargetGroups, buildScope, packageFamily, scopedFamilies, the release partial-target rejection in resolveContext, and the dependency-pinning branch in bumpPackageJsons are all pure/easily-testable functions gating real production npm publishes, but have no unit tests. This matches the existing convention for scripts/publish (no test suite there today), so not a regression, but since this logic directly controls what gets published where, some coverage would help catch regressions before they hit a release.

Nothing here is blocking — mostly polish/hardening suggestions on top of what looks like a well-thought-out change.