Conversation
Summary of ChangesHello @timon-schelling, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly refactors the project's build and execution mechanisms by introducing a new Rust-based command-line tool. This tool consolidates various Highlights
Changelog
Ignored Files
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request introduces a new building crate to replace the root package.json scripts for running and building the project, which is a great simplification. However, I've found a few issues in the implementation of this new tool. The command runner can panic on empty command strings, and the argument parsing logic doesn't correctly handle all the commands mentioned in the updated documentation, specifically cargo run build and cargo run -- production. I've provided suggestions to fix these issues, along with some minor improvements for code clarity and correctness.
16fca60 to
8cb8c29
Compare
8cb8c29 to
b7e0fac
Compare
b7e0fac to
f0f3969
Compare
f0f3969 to
deb2c6d
Compare
There was a problem hiding this comment.
6 issues found across 33 files
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name=".nix/default.nix">
<violation number="1" location=".nix/default.nix:47">
P2: The `// inputs` merge gives flake inputs precedence over explicitly constructed args. If a flake input name ever collides with a key like `lib`, `pkgs`, or `system`, the carefully constructed value will be silently overridden. Reverse the merge order so explicit values take precedence:
```nix
args = inputs // {
inherit system;
...
};
```</violation>
</file>
<file name="tools/building/src/lib.rs">
<violation number="1" location="tools/building/src/lib.rs:74">
P1: The `ExitStatus` returned by `.wait()` is silently discarded. If the spawned command exits with a non-zero status (i.e., fails), execution continues to the next command without any error. For a build tool where commands are chained sequentially, this means a failed step won't stop the pipeline. Check the exit status and panic (or return an error) on failure.</violation>
</file>
<file name="tools/third-party-licenses/src/main.rs">
<violation number="1" location="tools/third-party-licenses/src/main.rs:63">
P3: Prefer returning `ExitCode` from `main()` instead of calling `std::process::exit(1)`. This avoids bypassing Rust's stack unwinding and is the idiomatic way to signal a non-zero exit code now that the heavy lifting is in `run()`.
(Based on your team's feedback about avoiding `exit()` and preferring returning for cleanup.) [FEEDBACK_USED]</violation>
</file>
<file name="desktop/bundle/src/common.rs">
<violation number="1" location="desktop/bundle/src/common.rs:50">
P2: Return an error instead of panicking so callers can handle command failures via the Result the function already exposes.</violation>
</file>
<file name=".github/workflows/comment-!build-commands.yml">
<violation number="1" location=".github/workflows/comment-!build-commands.yml:85">
P0: The `!build-debug` command will never work. The job-level `if` condition (line 24) still gates on `!build-dev`, so a `!build-debug` comment won't even start the job. The job-level condition, the usage comment (line 3), and the error message (line 92) all need to be updated from `!build-dev` to `!build-debug` to match this rename.</violation>
</file>
<file name="tools/building/src/deps.rs">
<violation number="1" location="tools/building/src/deps.rs:158">
P2: Bug: terminal check is on `stdout`, but the prompt is written to `stderr` and input is read from `stdin`. If `stdout` is redirected but `stdin`/`stderr` are terminals, this incorrectly skips the interactive prompt. The check should be on `std::io::stdin()` to determine if a user can respond interactively.</violation>
</file>
Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.
|
@timon-schelling I have started the AI code review. It will take a few minutes to complete. |
There was a problem hiding this comment.
3 issues found across 33 files
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="desktop/bundle/src/common.rs">
<violation number="1" location="desktop/bundle/src/common.rs:50">
P2: This function returns `Result<(), Box<dyn Error>>` but panics instead of returning an `Err`. While replacing `std::process::exit(1)` with `panic!` is a step in the right direction (it allows unwinding), the idiomatic fix is to return an error so callers can handle it via `?`. This keeps the `Result` return type meaningful and avoids bypassing cleanup.
(Based on your team's feedback about avoiding `exit()` and preferring returning for cleanup.) [FEEDBACK_USED]</violation>
</file>
<file name="tools/building/src/deps.rs">
<violation number="1" location="tools/building/src/deps.rs:158">
P2: Terminal check is on `stdout`, but all output goes to `stderr`. This should check `stderr` (where the prompt is printed) and/or `stdin` (where input is read). With the current code, piping stdout (common for build tools) would incorrectly suppress the interactive installation prompt.</violation>
</file>
<file name="tools/building/src/lib.rs">
<violation number="1" location="tools/building/src/lib.rs:53">
P2: Typo: `comand` should be `command`. This misspelling appears in three public function signatures and a local variable, making it part of the public API.
(Based on your team's feedback about using consistent, precise terminology in names and docs.) [FEEDBACK_USED]</violation>
</file>
Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.
5b23aa7 to
5e82b97
Compare
| @@ -0,0 +1,193 @@ | |||
| use std::io::IsTerminal; | |||
There was a problem hiding this comment.
I think the name of the file deps.rs is not as useful as it could be. I think something like build_deps/ build_dependenices/build_tools would be more descriptive
TrueDoctor
left a comment
There was a problem hiding this comment.
Other than a couple of nits, the code looks good
c9d117e to
9bc512d
Compare
depends on #3808