Skip to content

fix: handle --help flag in gws auth setup#303

Open
zerone0x wants to merge 2 commits intogoogleworkspace:mainfrom
zerone0x:fix/auth-setup-help-flag
Open

fix: handle --help flag in gws auth setup#303
zerone0x wants to merge 2 commits intogoogleworkspace:mainfrom
zerone0x:fix/auth-setup-help-flag

Conversation

@zerone0x
Copy link
Contributor

@zerone0x zerone0x commented Mar 8, 2026

Summary

  • Adds early -h/--help detection in run_setup() that prints usage and returns before any gcloud or setup checks run
  • Prevents gws auth setup --help from failing with a gcloud-not-found error on machines without gcloud installed
  • Adds unit tests for the is_help_requested helper

Fixes #280

Test plan

  • cargo test -- setup passes (92 tests including 3 new ones)
  • cargo clippy -- -D warnings clean
  • Verify gws auth setup --help prints usage and exits 0
  • Verify gws auth setup --help does not require gcloud

🤖 Generated with Claude Code

zerone0x and others added 2 commits March 8, 2026 14:26
The +triage helper uses the `q` query parameter when listing messages,
but Gmail's metadata scope does not support `q` and returns 403. When a
user's OAuth token includes both gmail.metadata and gmail.modify scopes,
the API may resolve to the metadata code path and reject the query.

Switch +triage from gmail.modify to gmail.readonly, which is the
minimum scope that supports query filtering and aligns with the
read-only nature of the triage command.

Fixes googleworkspace#265

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
When `gws auth setup --help` is invoked on a machine without gcloud,
the command errors instead of printing help. This adds an early check
for -h/--help that prints usage info and exits before any setup logic.

Fixes googleworkspace#280

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@changeset-bot
Copy link

changeset-bot bot commented Mar 8, 2026

🦋 Changeset detected

Latest commit: d51e780

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package
Name Type
@googleworkspace/cli Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

@googleworkspace-bot googleworkspace-bot added area: auth area: core Core CLI parsing, commands, error handling, utilities labels Mar 8, 2026
@google-cla
Copy link

google-cla bot commented Mar 8, 2026

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

@gemini-code-assist
Copy link
Contributor

Summary of Changes

Hello, 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 enhances the gws CLI by improving the user experience for the auth setup command's help flag and resolving an authentication scope issue for the gmail +triage functionality. These changes make the CLI more robust and user-friendly, particularly for new users or specific Gmail operations.

Highlights

  • Improved gws auth setup help handling: The gws auth setup command now correctly displays usage information and exits early when --help or -h flags are provided, preventing errors on systems without gcloud installed.
  • Fixed Gmail triage scope: The gmail +triage command now uses the gmail.readonly scope instead of gmail.modify to resolve a 403 error. This change ensures compatibility with the q query parameter, which is not supported when gmail.metadata and gmail.modify scopes are combined.
Changelog
  • .changeset/fix-auth-setup-help-flag.md
    • Added a new changeset file documenting the fix for the --help flag in gws auth setup.
  • .changeset/fix-gmail-triage-scope.md
    • Added a new changeset file documenting the fix for the Gmail triage scope issue.
  • src/helpers/gmail/mod.rs
    • Introduced a new constant GMAIL_READONLY_SCOPE for Gmail API access.
  • src/helpers/gmail/triage.rs
    • Updated the authentication logic to use GMAIL_READONLY_SCOPE for the handle_triage function, addressing a 403 error when using the q query parameter.
  • src/setup.rs
    • Defined SETUP_USAGE constant for the gws auth setup help message.
    • Implemented is_help_requested function to detect --help or -h flags.
    • Added early exit logic in run_setup to display help message if requested.
    • Included new unit tests for the is_help_requested function.
Activity
  • The pull request was generated using Claude Code.
  • The author has verified that cargo test -- setup passes, including 3 new tests.
  • The author has confirmed cargo clippy -- -D warnings is clean.
  • The author plans to verify gws auth setup --help prints usage and exits 0.
  • The author plans to verify gws auth setup --help does not require gcloud.
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 Generative AI Prohibited Use Policy, 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 introduces two main changes. First, it adds handling for the --help and -h flags to the gws auth setup command, ensuring that the help message is displayed without running any pre-checks like gcloud availability. Second, it corrects the authentication scope for the gmail +triage command from gmail.modify to gmail.readonly to fix a 403 error.

My review identifies a correctness issue in the implementation of the help flag handling. The current approach can misinterpret command-line arguments, treating values for options as help flags. I've provided a suggestion to create a more robust argument parser that correctly distinguishes between flags and values.

Comment on lines +1442 to 1453
fn is_help_requested(args: &[String]) -> bool {
args.iter().any(|arg| arg == "--help" || arg == "-h")
}

/// Run the full setup flow. Orchestrates all steps and outputs JSON summary.
pub async fn run_setup(args: &[String]) -> Result<(), GwsError> {
if is_help_requested(args) {
println!("{SETUP_USAGE}");
return Ok(());
}

let opts = parse_setup_args(args);
Copy link
Contributor

Choose a reason for hiding this comment

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

high

The current implementation with a separate is_help_requested function is too simplistic and can lead to incorrect behavior. For example, a command like gws auth setup --project -h would be misinterpreted as a request for help, when the user likely intends to set the project ID to "-h". The is_help_requested function doesn't consider the argument's context.

To fix this, the argument parsing logic should be consolidated. Instead of a separate help check, the main argument parser should also handle the help flags. This ensures that option values are not mistaken for flags.

I suggest replacing both is_help_requested and the call to parse_setup_args with a single, more robust parsing loop at the beginning of run_setup.

    let mut project = None;
    let mut dry_run = false;
    let mut i = 0;
    while i < args.len() {
        match args[i].as_str() {
            "--help" | "-h" => {
                println!("{SETUP_USAGE}");
                return Ok(());
            }
            "--project" => {
                if i + 1 < args.len() {
                    project = Some(args[i + 1].clone());
                    i += 2;
                } else {
                    i += 1; // Or return an error for missing value
                }
            }
            s if s.starts_with("--project=") => {
                project = Some(s.split_once('=').unwrap().1.to_string());
                i += 1;
            }
            "--dry-run" => {
                dry_run = true;
                i += 1;
            }
            _ => {
                i += 1;
            }
        }
    }
    let opts = SetupOptions { project, dry_run };

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area: auth area: core Core CLI parsing, commands, error handling, utilities

Projects

None yet

2 participants