-
Notifications
You must be signed in to change notification settings - Fork 23
feat: Add flags for prompt values to upgrade command #87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #87 +/- ##
==========================================
- Coverage 63.17% 63.15% -0.02%
==========================================
Files 210 210
Lines 22186 22242 +56
==========================================
+ Hits 14015 14048 +33
- Misses 7084 7108 +24
+ Partials 1087 1086 -1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Last commit improves error handling in the automatic updates flow by:
These changes ensure that if an error occurs during automatic updates, it will |
mwbrooks
left a comment
There was a problem hiding this comment.
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 👾
With our current default prompt being "no" for the To me 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 Could these boolean flags for the prompt make sense? |
|
Matching specific confirmation prompts might be an interesting pattern to use with something like this as well: |
|
Great point @zimeg that
You also bring up a good point that the I did some research and common approaches are:
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:
|
Replace --auto-approve flag with component-specific flagsThis change allows users to selectively upgrade components rather than using a single auto-approve flag. Implementation Review
|
|
Once we're code complete here and everything looks good, I'll work on the e2e test! |
21fe3f7 to
24ec54b
Compare
zimeg
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👁️🗨️ Quick note on some confusion I'm finding in outputs when testing this. I hope to review the code changes soon, but want to make sure this is updating as expected first!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
📝 Before this merges I think we will want to make a separate PR for these rules.
It might also be worth considering our review process for these, but I'm favoring quick review with welcomed follow up. Saving more rambles for the other PR though 🫡
| }, "\n"), | ||
| Example: style.ExampleCommandsf([]style.ExampleCommand{ | ||
| {Command: "upgrade", Meaning: "Check for any available updates"}, | ||
| {Command: "upgrade --cli", Meaning: "Check for CLI updates and automatically upgrade without confirmation"}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤔 For some reason this flag is causing me to update twice which doesn't seem to be happening in earlier versions. This might be due to my setups, but please let me know if this is unexpected!
$ lack update --cli
🌱 A new version of the Slack CLI is available:
v3.1.0-26-g24ec54b → 3.1.0
You can read the release notes at:
https://docs.slack.dev/changelog
To manually update, visit the download page:
https://tools.slack.dev/slack-cli
✓ Installing update automatically...
Starting the auto-update...
Downloading version 3.1.0...
Found current install path: /Users/eden.zimbelman/programming/tools/slack-cli/bin/slack
Extracting the download: /Users/eden.zimbelman/.slack/bin/3.1.0
Backing up current install: /Users/eden.zimbelman/.slack/bin/backups/v3.1.0-26-g24ec54b
Updating to version 3.1.0: /Users/eden.zimbelman/programming/tools/slack-cli/bin/slack
Successfully updated to version 3.1.0
Verifying the update...
🌱 A new version of the Slack CLI is available:
v3.1.0-26-g24ec54b → 3.1.0
You can read the release notes at:
https://docs.slack.dev/changelog
To manually update, visit the download page:
https://tools.slack.dev/slack-cli
Starting the auto-update...
Downloading version 3.1.0...
Found current install path: /Users/eden.zimbelman/programming/tools/slack-cli/bin/slack
Extracting the download: /Users/eden.zimbelman/.slack/bin/3.1.0
Backing up current install: /Users/eden.zimbelman/.slack/bin/backups/v3.1.0-26-g24ec54b
Updating to version 3.1.0: /Users/eden.zimbelman/programming/tools/slack-cli/bin/slack
Successfully updated to version 3.1.0
Verifying the update...
$ lack version
Using lack v3.1.0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
back on this today! will have to try it out locally and see what's going on!
| --cli automatically approve and install CLI updates without prompting | ||
| -h, --help help for upgrade | ||
| --sdk automatically approve and install SDK updates without prompting | ||
| ``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
these docs are auto-generated, updating in source will update this page
Summary of changes
--auto-approveto theupgradecommandInstallUpdatesWithoutPromptto theUpdateNotificationtype for handling auto-approved updatesPrintUpdateNotificationmethods to check for the flag and bypass confirmationThis PR enables:
The flag follows established patterns in the codebase for command options, with appropriate documentation and test coverage to ensure reliability.
Tests Added
TestUpgradeCommandto verify behavior with and without the flagDocs Updated
docs/reference/commands/slack_upgrade.mdReasoning for implementation
The upgrade command needed a way to be run non-interactively, especially for automation and scripting use cases. The
--auto-approveflag 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:
Requirements