Fix failing CI: cargo bin target selection, rustfmt, and clippy#302
Merged
Conversation
The Rust CI pipelines were all red for two independent reasons: - cli-smoke, catalyst-oracle and xcode-tests run `cargo build --bin sweetpad` from `working-directory: sweetpad-lib`. After the workspace split the `sweetpad` binary lives in the `sweetpad-cli` package, so cargo scopes `--bin` to the current member (sweetpad-lib) and fails with "no bin target named `sweetpad` in default-run packages". Select the package explicitly with `-p sweetpad-cli`. - The sweetpad-lib job failed at `cargo fmt --all --check`; reformat the tree so it is rustfmt-clean. With formatting fixed the job now reaches `cargo clippy -D warnings`, which surfaced four pre-existing lints: - app.rs `plan`: allow `too_many_lines` (matches build_context.rs precedent) - mod.rs: terminate the NDJSON `println!` arm with a semicolon - state.rs: hoist the `SAVE_SEQ` static above the statements in `save` - adversarial_inputs.rs: use `BTreeMap::default()` instead of `Default::default()` fmt, clippy and `cargo test --workspace` all pass locally. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Y2qAHe2kPbo3Q8ZCXzvJxh
With the build-target fix in place, the macOS jobs now reach the CLI e2e
scripts, which parsed `--json` output at the top level and died with
`KeyError` (summary / targets / destinations). Every `--json` result is the
standardized `{schema, ok, data}` success envelope (output.rs::json_value —
"the single success-envelope site"); the scripts predate it and were never
exercised because the earlier `cargo build` step always failed first.
Read fields through the `data` payload:
- smoke.sh: unwrap once in the `assert_json` helper (all field expressions
were written against the bare payload) and in the inline destination-list
parser.
- catalyst-oracle.sh: `resolver_key` reads `d["data"]["targets"][0]["settings"]`.
- hot-reload-e2e.sh: unwrap the destination-list parser.
Verified the unwrap against real `doctor --json` and `settings show --json`
output; all three scripts pass `bash -n`.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y2qAHe2kPbo3Q8ZCXzvJxh
…ands `sweetpad simulator screenshot --output <file>` (and `record`/`bsp init`, which had the same flag) panicked at parse time: Mismatch between definition and access of `output`. Could not downcast to OutputMode, need to downcast to std::path::PathBuf The global `-o/--output` output-mode selector (GlobalArgs, `global = true`) and these subcommands' `--output <file>` flags both registered the clap id `output` with different value types; clap stored the PathBuf and the derived GlobalArgs accessor then tried to read it as OutputMode. The CLI e2e smoke test tripped it on the first `screenshot --output` call — previously masked because the `cargo build` step failed before the tests ran. The global `-o/--output` mode flag is the documented, unit-tested, cross-cutting contract, so it keeps `--output`; the three file-destination flags move to `--output-file` (distinct id, no collision). Updated CLI_DESIGN.md and the smoke test to match. Verified `screenshot --help` now shows both `--output-file` and `-o/--output`, the previously-panicking invocation returns a clean error envelope, and `--output json` still selects JSON mode. fmt, clippy and `cargo test --workspace` pass. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Y2qAHe2kPbo3Q8ZCXzvJxh
The CLI e2e smoke test now runs to its final "error paths" section, where it asserted that an unknown scheme, a missing container, and an unknown simulator each exit 1. They are all `ErrorKind::TargetResolution`, which the CLI's deliberate exit-code taxonomy maps to 4 (Generic 1, BuildFailure 3, TargetResolution 4, ToolMissing 5, UserCancel 6 — see ErrorKind::exit_code, which is unit-tested). The `expect_code 1` lines were written before that taxonomy and never ran (the build step failed first). Verified in a clean working directory that `derived-data path` (no container) and `build start --scheme NoSuchScheme` both exit 4; `simulator screenshot` against an unknown target takes the same TargetResolution path on a runner where xcrun is present. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Y2qAHe2kPbo3Q8ZCXzvJxh
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The Rust CI pipelines were all red for two independent reasons:
cli-smoke, catalyst-oracle and xcode-tests run
cargo build --bin sweetpadfrom
working-directory: sweetpad-lib. After the workspace split thesweetpadbinary lives in thesweetpad-clipackage, so cargo scopes--binto the current member (sweetpad-lib) and fails with"no bin target named
sweetpadin default-run packages". Select thepackage explicitly with
-p sweetpad-cli.The sweetpad-lib job failed at
cargo fmt --all --check; reformat the treeso it is rustfmt-clean. With formatting fixed the job now reaches
cargo clippy -D warnings, which surfaced four pre-existing lints:plan: allowtoo_many_lines(matches build_context.rs precedent)println!arm with a semicolonSAVE_SEQstatic above the statements insaveBTreeMap::default()instead ofDefault::default()fmt, clippy and
cargo test --workspaceall pass locally.Co-Authored-By: Claude Opus 4.8 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_01Y2qAHe2kPbo3Q8ZCXzvJxh