Skip to content

Conversation

@mwbrooks
Copy link
Member

CHANGELOG

Update the slack run command to create and install new & existing Bolt Framework apps that are configured to app settings as the source of truth (i.e. remote manifest).

Summary

This pull request updates the slack run command to create and install new & existing apps that use app settings as the source of truth (remote manifest).

Preview

slack run creates a new Bolt App with app settings as the source of truth

2025-05-29-run-new-bolt-app.mov

slack run uses an existing Bolt App with app settings as the source of truth

2025-05-29-run-existing-bolt-app.mov

Reviewer

# Run new ROSI app without experiment
$ lack create asdf -t slack-samples/deno-starter-template
$ cd asdf/
$ lack run
# → Select "create new app"
# → Confirm run starts
# → Press CTRL+C

# Run existing ROSI app without experiment
$ lack run
# → Select existing app
# → Confirm run starts
# → Press CTRL+C

# Clean up ROSI app
$ lack delete -f
$ cd ../
$ rm -rf asdf/

# ---

# Run new ROSI app with experiment
$ lack create asdf -t slack-samples/deno-starter-template --experiment bolt-install
$ cd asdf/
$ lack run --experiment bolt-install
# → Select "create new app"
# → Confirm run starts
# → Press CTRL+C

# Run existing ROSI app with experiment
$ lack run --experiment bolt-install
# → Select existing app
# → Confirm run starts
# → Press CTRL+C

# Clean up ROSI app
$ lack delete -f
$ cd ../
$ rm -rf asdf/

# ---

# Run new Bolt app without experiment
$ lack create asdf -t slack-samples/bolt-js-starter-template
$ cd asdf/
$ lack run
# → Select existing app
# → Confirm run starts
# → Press CTRL+C
# Note: This works because the manifest source is local from the create command without the experiment

# Clean up Bolt app
$ lack delete -f
$ cd ../
$ rm -rf asdf/

# ---

# Run new Bolt app with experiment
$ lack create asdf -t slack-samples/bolt-js-starter-template --experiment bolt-install
$ cd asdf/
$ lack run --experiment bolt-install
# → Select existing app
# → Confirm run starts
# → Press CTRL+C

# Run existing Bolt app with experiment
$ lack run --experiment bolt-install
# → Select existing app
# → Confirm run starts
# → Press CTRL+C

# Run existing Bolt app WITHOUT experiment
$ lack run
# → Confirm error "sdk_hook_invocation_failed"
# Note: Trying to run without the experiment so developerInstall endpoint doesn't return tokens

# Clean up Bolt app
$ lack delete -f
$ cd ../
$ rm -rf asdf/

Requirements

@mwbrooks mwbrooks self-assigned this May 29, 2025
@mwbrooks mwbrooks added enhancement M-T: A feature request for new functionality changelog Use on updates to be included in the release notes experiment Experimental feature accessed behind the --experiment flag or toggle semver:minor Use on pull requests to describe the release version increment labels May 29, 2025
@codecov
Copy link

codecov bot commented May 29, 2025

Codecov Report

Attention: Patch coverage is 68.42105% with 12 lines in your changes missing coverage. Please review.

Project coverage is 63.45%. Comparing base (debfc8c) to head (1b3238c).
Report is 1 commits behind head on main.

Files with missing lines Patch % Lines
internal/pkg/apps/install.go 61.29% 8 Missing and 4 partials ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #111      +/-   ##
==========================================
- Coverage   63.46%   63.45%   -0.01%     
==========================================
  Files         212      212              
  Lines       22308    22335      +27     
==========================================
+ Hits        14157    14172      +15     
- Misses       7062     7068       +6     
- Partials     1089     1095       +6     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Copy link
Member Author

@mwbrooks mwbrooks left a comment

Choose a reason for hiding this comment

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

🪄 A few comments for the kind reviewers!

Comment on lines +344 to +347
if !clients.Config.WithExperimentOn(experiment.BoltInstall) {
if !manifestUpdates && !manifestCreates {
return app, api.DeveloperAppInstallResult{}, "", nil
}
Copy link
Member Author

Choose a reason for hiding this comment

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

note: InstallLocalApp now continues even with there are no manifest updates or creates. This is because it must still install the app in order to get the tokens.

Comment on lines +674 to +677
// When the BoltInstall experiment is enabled, apps can always be created with any manifest source.
if clients.Config.WithExperimentOn(experiment.BoltInstall) {
return app.AppID == "", nil
}
Copy link
Member Author

Choose a reason for hiding this comment

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

note: shouldCreateManifest now always returns true when the experiment is turned on because both local and remote manifest sources can be created.

Copy link
Member

Choose a reason for hiding this comment

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

@mwbrooks This is so good! 🧠 ✨

As later follow up we might want to wrap errors from .GetManifestLocal to suggest linking an created on app on app settings if the get-manifest hook errors for some reason and the manifest source is remote.

No blocker for this PR since IMO error handling is another discussion altogether!

Copy link
Member

Choose a reason for hiding this comment

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

Edit: This might be best to note for the conclusion of this experiment to let us streamline some of the logic above and make this case more clear 🤔

Copy link
Member Author

Choose a reason for hiding this comment

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

This is a really great suggestion! I think it would help developers move forward who don't have a local manifest file. I've made a note to follow-up on this error suggestion. ✏️

Comment on lines +1165 to +1167
isManifestSourceLocal := manifestSource.Equals(config.ManifestSourceLocal)
isBoltInstallEnabled := clients.Config.WithExperimentOn(experiment.BoltInstall)
if isManifestSourceLocal || isBoltInstallEnabled {
Copy link
Member Author

Choose a reason for hiding this comment

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

note: Updated the app select to display "create a new app" for both local and remote manifest sources. This means the slack install now displays "create a new app" for remote projects, even though it doesn't work. However, I think this is acceptable because is currently returns an error and the update continues to return an error. We'll follow-up this PR with support for slack install.

Comment on lines +271 to +274
if !strings.HasSuffix(name, LocalRunNameTag) {
name = name + " " + LocalRunNameTag
}
return name
Copy link
Member Author

Choose a reason for hiding this comment

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

note: Fixed a bug where (local) was appended multiple times.

@mwbrooks mwbrooks marked this pull request as ready for review May 29, 2025 22:00
@mwbrooks mwbrooks requested review from a team as code owners May 29, 2025 22:00
Copy link
Member

@zimeg zimeg left a comment

Choose a reason for hiding this comment

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

LGTM! The test cases are quite precise and review instructions were helpful 🙏 ✨

All is working well for me but I left a note on perhaps enhanced error logging and I also noticed that updating the manifest.json file while the app is running - despite having a remote source - causes a reinstallation to happen.

AFAICT this is unrelated to these changes, but I'm starting to think about how these manifest sources can be as one 👁️‍🗨️

No blockers and a huge unlock for the quickstart experience! 🔏

Comment on lines +674 to +677
// When the BoltInstall experiment is enabled, apps can always be created with any manifest source.
if clients.Config.WithExperimentOn(experiment.BoltInstall) {
return app.AppID == "", nil
}
Copy link
Member

Choose a reason for hiding this comment

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

@mwbrooks This is so good! 🧠 ✨

As later follow up we might want to wrap errors from .GetManifestLocal to suggest linking an created on app on app settings if the get-manifest hook errors for some reason and the manifest source is remote.

No blocker for this PR since IMO error handling is another discussion altogether!

Comment on lines +674 to +677
// When the BoltInstall experiment is enabled, apps can always be created with any manifest source.
if clients.Config.WithExperimentOn(experiment.BoltInstall) {
return app.AppID == "", nil
}
Copy link
Member

Choose a reason for hiding this comment

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

Edit: This might be best to note for the conclusion of this experiment to let us streamline some of the logic above and make this case more clear 🤔

Comment on lines 371 to 373
// When the BoltInstall experiment is enabled, we need to get the manifest from the local file
// if the manifest source is local or if we are creating a new app. Otherwise, we get the manifest
// from the app settings.
Copy link
Member

Choose a reason for hiding this comment

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

@mwbrooks Small suggestion - it might be nice to note why we're collecting a remote manifest here? 📚

Copy link
Member Author

Choose a reason for hiding this comment

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

@zimeg Thanks for catching this! Commit 1b3238c clarifies why we get the manifest from the local file when creating (or when the manifest source is local), while using app settings for updates and installations. 📝

"create a new run on slack app with a local function runtime using expected rosi defaults": {
isExperimental: false,
mockApp: types.App{},
"create and install a new ROSI app with a local function runtime using expected rosi defaults when the BoltInstall experiment is disabled": {
Copy link
Member

Choose a reason for hiding this comment

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

@mwbrooks Thanks for updating these test titles with the BoltInstall experiment status - huge help in later refactors 🪓

Copy link
Member Author

Choose a reason for hiding this comment

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

@zimeg Thanks! It added some noise to the PR Review, but keeping the wording consistent will hopefully make removing the experiment a little easier.

Comment on lines +1273 to +1275
expectedCreate: false,
expectedInstallState: types.InstallSuccess,
expectedUpdate: false,
Copy link
Member

Choose a reason for hiding this comment

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

@mwbrooks Wonderful 👾 ✨

@mwbrooks
Copy link
Member Author

Thanks for the quick and thorough review @zimeg! 🙇🏻

All is working well for me but I left a note on perhaps enhanced error logging and I also noticed that updating the manifest.json file while the app is running - despite having a remote source - causes a reinstallation to happen.

Oh, this is a really good catch! 🏒 🥅 I imagine the ideal behaviour would be something along the lines of a warning message when the local manifest file is changed and the source is remote. This would help reduce some confusion. I think we could do something similar at during any command that detects the local file has changed (cached hash). I'll make a note about this as a future enhancement. 💎

@mwbrooks mwbrooks merged commit 11ef1dc into main May 30, 2025
7 checks passed
@mwbrooks mwbrooks deleted the mwbrooks-bolt-install-run branch May 30, 2025 13:19
@mwbrooks mwbrooks added semver:patch Use on pull requests to describe the release version increment and removed semver:minor Use on pull requests to describe the release version increment labels May 30, 2025
@zimeg
Copy link
Member

zimeg commented May 30, 2025

I imagine the ideal behaviour would be something along the lines of a warning message when the local manifest file is changed and the source is remote.

@mwbrooks 🧠 ✨ Wow this is so much better than a silent and confusing success! Thanks much for keeping note and making changes all around.

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

Labels

changelog Use on updates to be included in the release notes enhancement M-T: A feature request for new functionality experiment Experimental feature accessed behind the --experiment flag or toggle semver:patch Use on pull requests to describe the release version increment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants