Thanks to visit codestin.com
Credit goes to github.com

Skip to content

fix(docker): include experiments/ in builder so workspace manifest parses#235

Merged
WaylandYang merged 1 commit into
mainfrom
fix/dockerfile-experiments
Jun 8, 2026
Merged

fix(docker): include experiments/ in builder so workspace manifest parses#235
WaylandYang merged 1 commit into
mainfrom
fix/dockerfile-experiments

Conversation

@WaylandYang

Copy link
Copy Markdown
Contributor

Summary

The Dockerfile only copied crates ./crates into the builder stage, but the workspace Cargo.toml lists experiments/v0.4-* as members. Cargo refuses to parse the workspace manifest without their per-crate manifests present, so cargo build --release --bin forkd-controller died with No such file or directory on experiments/v0.4-uffd-wp-poc/Cargo.toml.

This broke release.yml's build + push Docker image job from v0.5.0 through v0.5.2 — the tarball, PyPI, and npm publishes all succeeded each release, but the ghcr.io controller image was never pushed.

Fix

Add COPY experiments ./experiments to the builder stage. Experiments aren't selected by --bin forkd-controller so they don't compile; cargo just needs them present to parse the workspace.

Verification (dev box)

$ docker build -t forkd-controller:test .
[builds clean]
$ docker images forkd-controller:test
forkd-controller   test   4b97d5a97b24   152MB
$ docker run --rm --entrypoint /usr/local/bin/forkd-controller forkd-controller:test --version
forkd-controller 0.5.2

Test plan

  • CI green
  • After merge: next v* tag push will exercise this in release.yml → ghcr.io/deeplethe/forkd-controller:vX.Y.Z gets pushed for the first time since v0.4

🤖 Generated with Claude Code

…rses

The Dockerfile only COPYed `crates ./crates`, but the workspace
`Cargo.toml` lists `experiments/v0.4-*` as members. Cargo refuses
to parse the workspace manifest without their per-crate manifests
present, so `cargo build --release --bin forkd-controller` died with
'No such file or directory' on `experiments/v0.4-uffd-wp-poc/Cargo.toml'.

This broke `release.yml`'s `build + push Docker image` job from v0.5.0
through v0.5.2 — the tarball, PyPI, and npm publishes all succeeded,
but the ghcr.io controller image was never pushed.

Fix: COPY the experiments dir into the builder. They're not selected
by `--bin forkd-controller` so they don't compile, but cargo can now
parse the manifest. Adds ~100 KB of source to the builder stage; the
final runtime image is unchanged.

Verified on dev box: image builds clean (152 MB), forkd-controller 0.5.2
runs from the image.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
@WaylandYang WaylandYang merged commit c65593e into main Jun 8, 2026
2 checks passed
@WaylandYang WaylandYang deleted the fix/dockerfile-experiments branch June 8, 2026 02:38
WaylandYang added a commit that referenced this pull request Jun 11, 2026
…ed (#238)

publish-pypi.yml was failing with HTTP 400 'File already exists' when a
v* tag got force-pushed (e.g. when fixing release.yml's Docker job for
v0.5.2 — see #235). The publish step has nothing to do, but the action
defaults to skip-existing=false, so the no-op surfaces as a failure.

Set skip-existing=true: PyPI immutability means re-publish is a logical
no-op anyway, and treating it as a hard error means every tag-fix dance
leaves a red X behind that's actually a non-event.

Co-authored-by: Claude Opus 4.7 (1M context) <[email protected]>
WaylandYang added a commit that referenced this pull request Jun 11, 2026
* fix(ci): pypi-publish skip-existing=true so re-pushed tags don't go red

publish-pypi.yml was failing with HTTP 400 'File already exists' when a
v* tag got force-pushed (e.g. when fixing release.yml's Docker job for
v0.5.2 — see #235). The publish step has nothing to do, but the action
defaults to skip-existing=false, so the no-op surfaces as a failure.

Set skip-existing=true: PyPI immutability means re-publish is a logical
no-op anyway, and treating it as a hard error means every tag-fix dance
leaves a red X behind that's actually a non-event.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

* feat(cli): forkd quickstart — zero-to-first-fork in one command

Conversion-funnel work: stars are growing ~10x faster than downloads,
and the most-cited reason is first-run friction (host setup, kernel
download, snapshot bake, netns provisioning — four manual steps across
two scripts and three verbs before the first fork).

`sudo -E forkd quickstart` collapses that to one command:

1. doctor::preflight() — hard-gates on platform/KVM/firecracker;
   reports kernel/tap/docker as data rather than failures
2. Heals what's missing WITH CONSENT (or --yes): guest kernel
   download, tap creation, netns provisioning. The setup scripts are
   embedded via include_str! so a tarball install works without the
   repo checked out; an interactive prompt lists exactly what will be
   touched before anything runs. Nothing on the host changes without
   an explicit yes.
3. Snapshot: reuse existing > bake from python:3.12-slim via local
   Docker (preferred — uses *this host's* Firecracker, so the vmstate
   can never hit cross-FC-version restore errors) > hub pull fallback
   with a compat warning.
4. fork -n 10 --per-child-netns, then prints next steps.

Idempotent: re-running skips completed setup and reuses the snapshot.

README: new "One command" section at the top of Quick start; stale
v0.3.4 tarball URLs bumped to v0.5.2.

Co-Authored-By: Claude Fable 5 <[email protected]>

---------

Co-authored-by: Claude Opus 4.7 (1M context) <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant