Skip to content

refactor: simplify --exit-code from integer to boolean flag#140

Open
jbovet wants to merge 2 commits intomainfrom
fix-exit-code
Open

refactor: simplify --exit-code from integer to boolean flag#140
jbovet wants to merge 2 commits intomainfrom
fix-exit-code

Conversation

@jbovet
Copy link
Owner

@jbovet jbovet commented Feb 8, 2026

The exit_code option was an integer that behaved as a boolean.
Simplify to a true boolean flag: --exit-code enables exit code 1
on certificate issues, omitting it always exits 0.

Co-Authored-By: Claude Opus 4.6 noreply@anthropic.com

jbovet and others added 2 commits February 8, 2026 00:49
The exit_code option was an integer that behaved as a boolean.
Simplify to a true boolean flag: --exit-code enables exit code 1
on certificate issues, omitting it always exits 0.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@gemini-code-assist
Copy link
Contributor

Summary of Changes

Hello @jbovet, 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 streamlines the application's exit code handling by converting the --exit-code option from an integer that was implicitly treated as a boolean to an explicit boolean flag. This change enhances the clarity of the configuration, simplifies its usage, and aligns the implementation with its intended behavior of either enabling or disabling a non-zero exit code upon encountering certificate issues.

Highlights

  • Simplified Exit Code Flag: The --exit-code option has been refactored from an integer type (i32) to a boolean type (bool). Previously, it behaved as a boolean (0 for no exit code, 1 for exit code 1), and this change formalizes that behavior.
  • Clearer CLI Documentation: The command-line interface documentation for --exit-code has been updated to explicitly state that enabling it will cause the program to exit with code 1 on certificate issues, and it is disabled by default.
  • Type System Consistency: The underlying configuration structures (Config and FinalConfig) and related functions (from_cli_args, from_merged_config, exit) have been updated to consistently use bool for the exit_code parameter, improving type safety and clarity.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Changelog
  • src/config.rs
    • Changed the exit_code field in the Config struct from Option<i32> to Option<bool>.
    • Updated documentation comments and default values for exit_code to reflect its boolean nature (e.g., exit_code = true instead of exit_code = 1).
    • Modified the from_cli_args function signature to accept Option<bool> for the exit_code parameter.
    • Adjusted various test cases to use Some(true) or Some(false) when asserting or setting exit_code values.
  • src/main.rs
    • Updated the Args struct to define exit_code as a bool with default_value_t = false, removing the Option<i32> type.
    • Revised the CLI documentation for --exit-code to clearly explain its boolean function and the conditions for exiting with code 1.
    • Changed the exit_code field in the FinalConfig struct from i32 to bool.
    • Modified the FinalConfig::from_merged_config method to handle Option<bool> for the exit_code default value.
    • Adjusted the load_config function to pass the CLI exit_code as Some(true) or None to Config::from_cli_args.
    • Refactored the exit function to accept a bool for exit_code and to always exit with code 1 if exit_code is true and failed_result is true.
    • Updated test assertions to check for final_config.exit_code as a boolean (assert!(!final_config.exit_code) or assert!(final_config.exit_code)).
Activity
  • The pull request was authored by jbovet, with a co-authorship by Claude Opus 4.6, indicating a collaborative effort in its creation.
  • The changes primarily involve refactoring an existing configuration option to improve its type safety and clarity, suggesting a focus on code quality and maintainability.
Using Gemini Code Assist

The 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 /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

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 .gemini/ folder in the base of the repository. Detailed instructions can be found here.

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

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request refactors the --exit-code option from an integer to a boolean, which simplifies its usage. The changes are consistently applied across the configuration handling, main application logic, and tests.

My main feedback is regarding the command-line argument parsing for the new exit_code flag. The current implementation as a simple boolean flag removes the ability for a user to disable the exit code behavior from the CLI if it's enabled in a configuration file. I've suggested changing it to an Option<bool> to restore this functionality and align it with how other similar options are handled in the code.

Comment on lines +48 to +49
#[arg(long, default_value_t = false)]
exit_code: bool,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

While changing exit_code to a boolean is a good simplification, making it a simple flag (bool) removes the ability to disable it from the command line if it's enabled in a configuration file. The previous Option<i32> allowed this with --exit-code 0.

To maintain this flexibility and for consistency with other arguments like prometheus, I suggest using Option<bool>. This would allow --exit-code true and --exit-code false, providing clear override capability from the command line.

With this change, you can then simplify the call in load_config.

Suggested change
#[arg(long, default_value_t = false)]
exit_code: bool,
#[arg(long)]
exit_code: Option<bool>,

cli_addresses,
cli.output.as_ref().map(|o| o.to_string()),
cli.exit_code,
if cli.exit_code { Some(true) } else { None },
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

If you change exit_code in Args to Option<bool> as suggested in my other comment, you can simplify this to pass cli.exit_code directly. This avoids the conditional logic and correctly handles None when the argument is not provided, preserving the configuration file precedence.

Suggested change
if cli.exit_code { Some(true) } else { None },
cli.exit_code,

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