[FEATURE] shortcut for updating all triggers associated with an app

[brahn]

Description of the problem being solved

Dovetailing on #220 -- I have an app with three triggers. It would be extremely helpful if there were a way to update them all at once.

Context

I know from notes on #220 that there are a wide variety of use cases and configurations; mine is relatively simple:

• This is an internal, single-team app.
• There are three triggers, each currently managed with the slack trigger CLI command.
• Right now I have two app IDs versions: one for the deployed version and one for local development.

In my ideal world I could run

slack run --update-all-triggers
slack deploy --update-all-triggers

and the right thing would happen.

Alternative solutions

Writing my own little scripts that call all the relevant CLI commands. This is tedious to maintain as I create new triggers, etc.

[zimeg]

Hey @brahn! 👋 Thanks for sharing this request with us! 🤖 ✨

I understand that managing triggers across different apps can be tedious, but it's not clear to me what updating existing triggers might do across separate run commands?

Each trigger can have different definitions and various inputs that might not have a clear interface with such a bulk update option from what I can tell, but please feel free to share more details about this setup!

Writing my own little scripts that call all the relevant CLI commands.

For now this might be the recommended solution, but updating triggers at runtime is also possible if this is helpful:

📚 https://tools.slack.dev/deno-slack-sdk/guides/managing-triggers

[brahn]

@zimeg thanks for the quick reply!

First off, I appreciate the pointer to runtime updates -- I think a script using those typescript invocations may be preferable to a script that invokes the CLI.

For clarity, is your suggestion that I write a script with those invocations that would be run manually? Or is there a good place to hook into a running app?

In answer to your question --

it's not clear to me what updating existing triggers might do across separate run commands?

It might be that my use case is overly narrow, but here's how I'd like to be able to approach development --

• When developing, I make changes to my code. Those changes might be to triggers, workflows, functions, etc. I don't particularly distinguish, it's all part of my app's logic.
• As I make changes to my code, ideally the local version would "automatically" update all of its behavior, including the triggers.
• Absent a full automatic update, I'd like to be able to stop and restart everything all at once, so that I can be confident that the running dev version of the app fully reflects my modified code.
• Either way, I do not want to have to manage the cognitive load of "which parts of my app have been updated to current code and which parts haven't".
• When ready, I want to be able to do a full update of the deployed app (including triggers) all at once.

My understanding (and please correct me where this is awry!) is that

• The built-in watch capability of slack run does pick up some code changes -- e.g. changes to declared functions and the code they import get picked up -- but not all.
• In particular, trigger changes require running the CLI commands (and perhaps also changes to the manifest require a restart?)
• And similarly, deployment of new code requires both slack deploy and running the CLI commands to update the triggers.

[zimeg]

@brahn Likewise, thanks for clarifying this use case! 📚

For clarity, is your suggestion that I write a script with those invocations that would be run manually?

To avoid a complex and perhaps brittle setup I'd recommend running this script separate, though it might be possible to edit the get-manifest hook to call this script during reinstallation which happens on file changes.

In the .slack/hooks.json file, an edit might be:

{
  "hooks": {
    "get-manifest": "bash update.sh && deno run -q --config=deno.jsonc --allow-read --allow-net --allow-env --allow-sys=osRelease https://deno.land/x/deno_slack_hooks@1.4.0/get_manifest.ts",
    "get-hooks": "deno run -q --allow-read --allow-net https://deno.land/x/deno_slack_hooks@1.4.0/mod.ts"
  }
}

Though please know outputs will be surfaced in verbose logs - this is more of a hack and not a suggestion 😉

When developing, I make changes to my code. Those changes might be to triggers, workflows, functions, etc. I don't particularly distinguish, it's all part of my app's logic.

...deployment of new code requires both slack deploy and running the CLI commands to update the triggers.

Concepts that combine to make a workflow app are so often confusing because it does all appear in code, and your understanding of these changes is correct, but I'll share a few clarifications that I find helpful:

1. The app manifest defines features of an app - built from manifest.ts and shown with a slack manifest command.
2. Custom functions have definitions for the app manifest and handler code that reloads separate.
3. Workflow triggers connect events in the workspace to the workflows of an app from the manifest.

Automatic updates at the moment don't happen because triggers are a separate concept from the app manifest.

I do understand triggers are associated with a single workflow which might make these batch updates seem close, but we don't have immediate plans to improve this 😓

I am however also interested in possible approaches of making these updates if a trigger_id is present in the definition?

Problems might arise then when attempting to update triggers of a different app, but a workflow_app_id field might also exist to match this?

We'd be hoping to target the expected inputs of workflows.triggers.update with something like:

{
  "type": "shortcut",
  "name": "Give some kudos",
  "description": "Broadcast your appreciation with kind words and a GIF",
  "workflow": "#/workflows/give_kudos_workflow",
  "workflow_app_id": "A0123456789",
  "inputs": {
    "interactivity": {
      "value": "{{data.interactivity}}"
    }
  },
  "trigger_id": "Ft0123456789"
}

Edges exist around deleting triggers and runtime triggers with this idea, but for expected updates with app code this might be promising perhaps!

Please feel free to share thoughts on this while we keep this issue open! For now, I will recommend scripting these updates with the CLI or during runtime 👾