Summary of changes

• Added a new boolean flag --auto-approve to the upgrade command
• Added a new method InstallUpdatesWithoutPrompt to the UpdateNotification type for handling auto-approved updates
• Modified the dependencies' PrintUpdateNotification methods to check for the flag and bypass confirmation
• Updated command examples and help text to document the new flag

This PR enables:

• Automated CLI upgrade workflows in CI/CD pipelines
• Programmatic upgrades through the MCP server tools API
• Simplified upgrades for users who always want the latest version
• Better integration with scripts and other automation tools

The flag follows established patterns in the codebase for command options, with appropriate documentation and test coverage to ensure reliability.

Tests Added

• Updated TestUpgradeCommand to verify behavior with and without the flag
• Added a test case specifically for the auto-approve flag path
• Ensured all existing tests continue to pass

Docs Updated

• Added the flag to the command documentation in docs/reference/commands/slack_upgrade.md
• Added an example demonstrating usage of the flag
• Updated the options section to include the new flag with its description

Reasoning for implementation

The upgrade command needed a way to be run non-interactively, especially for automation and scripting use cases. The --auto-approve flag provides this functionality by skipping the confirmation prompt when installing updates.

While we could have modified the existing confirmation flow directly, creating a dedicated method provides better separation of concerns:

1. Keeps the standard interactive flow clean and focused
2. Makes the auto-approve path more explicit and maintainable
3. Reduces the risk of regression in either flow when changes are made

Requirements

• I've read and understood the Contributing Guidelines and have done my best effort to follow them.
• I've read and agree to the Code of Conduct.

Last commit improves error handling in the automatic updates flow by:

• Fixing linting error in cmd/upgrade/upgrade.go by properly checking the error returned from updateNotification.InstallUpdatesWithoutPrompt() when the --auto-approve flag is used.
• Adding comprehensive test coverage for error scenarios:
  • New TestUpgradeCommandWithAutoApproveError test in cmd/upgrade/upgrade_test.go
    to verify error propagation when auto-approve is enabled
  • New Test_Update_InstallUpdatesWithoutPrompt test in internal/update/update_test.go
    to test different error scenarios in the update notification process
• Improved test structure to correctly model the early-return behavior of the InstallUpdatesWithoutPrompt method, ensuring mock expectations are properly set when errors occur.

These changes ensure that if an error occurs during automatic updates, it will
be properly propagated back to the user rather than silently ignored, improving
reliability and user experience.

Choose a reason for hiding this comment

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

Great idea @kkemple and thanks for putting together a PR 👏🏻

We already have some conventions for disabling prompts and seeding a default answer. There are also some good conventions in the CLI community. So, I think I'd lean toward adopting those rather than introducing a new flag.

@zimeg Do you think this is a good place for the --no-prompt flag? We could also use the common convention of --yes | -y to default all prompts to "yes".

@mwbrooks Great suggestions and I also think this is a good idea to have for imperative automations 👾

Do you think this is a good place for the --no-prompt flag?

With our current default prompt being "no" for the upgrade command, I don't think this would be ideal. AFAICT this flag should instead error with the suggested flag alternative instead of make the default choice?

To me --yes is solid and --auto-approve makes sense too! I'd avoid --force since we're not overriding warnings here.

One concern I have with both options is that we sometimes have multiple prompts when upgrading, one for the CLI version and one for the SDK. Without being so verbose, matching one flag to one prompt might be the most sure, though developers using --yes might understand the effects of automating updates.

Could these boolean flags for the prompt make sense?

$ slack upgrade --cli
$ slack upgrade --sdk

Matching specific confirmation prompts might be an interesting pattern to use with something like this as well:

$ slack upgrade --confirm=cli --confirm=sdk

Great point @zimeg that --no-prompt always chooses the default, while --yes or --no would answer ALL prompts with a yes or no.

One concern I have with both options is that we sometimes have multiple prompts when upgrading, one for the CLI version and one for the SDK.

You also bring up a good point that the upgrade command can have 2 prompts: CLI and SDK.

I did some research and common approaches are:

• Skip all prompts using defaults: --no-prompt, --no-interactivity, --quiet
• Answer all prompts with a value: --yes or --no
• Answer each prompt with a specific value: --foo bar

So, I think we can come back to something that we discussed a good year ago: each prompt should have a flag.

In that case, something like this makes sense:

• Upgrade CLI: --cli=<bool>
• Upgrade SDK: --sdk=<bool>

Replace --auto-approve flag with component-specific flags

This change allows users to selectively upgrade components rather than using a single auto-approve flag.

Implementation Review

• ✅ Flag Definition: Implemented with clear, descriptive flag names and helpful descriptions
• ✅ Component Logic: The InstallUpdatesWithComponentFlags method correctly selects which components to update based on flags
• ✅ Documentation: All examples, help text, and reference docs have been updated to reflect the new flags
• ✅ Tests: Comprehensive tests cover all combinations and edge cases
• ✅ Code Cleanup: Removed the unused InstallUpdatesWithoutPrompt method and its tests since it was only created in this

Once we're code complete here and everything looks good, I'll work on the e2e test!

Choose a reason for hiding this comment

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