slack-samples/deno-virtual-running-buddies

Log runs and post a team leaderboard with stats once a week

Virtual Running Buddies

Log your running activities each week, and compare your team's progress from one week to the next with a leaderboard and stats.

Guide Outline:

• Setup
  • Install the Slack CLI
  • Clone the Sample
• Creating Triggers
• Datastores
• Testing
• Deploying Your App
• Viewing Activity Logs
• Project Structure
• Resources

---

Supported Workflows

• Log a run: Collect and store info about a recent run
• Display the leaderboard: Show team statistics and highlight the top runners from the past week

Setup

Before getting started, first make sure you have a development workspace where you have permission to install apps. Please note that the features in this project require that the workspace be part of a Slack paid plan.

Install the Slack CLI

To use this template, you need to install and configure the Slack CLI. Step-by-step instructions can be found in our Quickstart Guide.

Clone the Sample

Start by cloning this repository:

# Clone this project onto your machine
$ slack create my-app -t slack-samples/deno-virtual-running-buddies

# Change into the project directory
$ cd my-app

Creating Triggers

Triggers are what cause workflows to run. These triggers can be invoked by a user, or automatically as a response to an event within Slack.

When you run or deploy your project for the first time, the CLI will prompt you to create a trigger if one is found in the triggers/ directory. For any subsequent triggers added to the application, each must be manually added using the trigger create command.

When creating triggers, you must select the workspace and environment that you'd like to create the trigger in. Each workspace can have a local development version (denoted by (local)), as well as a deployed version. Triggers created in a local environment will only be available to use when running the application locally.

Link Triggers

A link trigger is a type of trigger that generates a Shortcut URL which, when posted in a channel or added as a bookmark, becomes a link. When clicked, the link trigger will run the associated workflow.

Link triggers are unique to each installed version of your app. This means that Shortcut URLs will be different across each workspace, as well as between locally run and deployed apps.

With link triggers, after selecting a workspace and environment, the output provided will include a Shortcut URL. Copy and paste this URL into a channel as a message, or add it as a bookmark in a channel of the workspace you selected. Interacting with this link will run the associated workflow.

Note: triggers won't run the workflow unless the app is either running locally or deployed!

Scheduled Triggers

A scheduled trigger runs workflows on a specific cadence and requires no interaction after being created.

Similar to link triggers, these are unique to each version of your app and can be created multiple times with various inputs. After being created, and once the time is right, these will automatically invoke the workflow.

Manual Trigger Creation

To manually create triggers for logging runs and displaying stats for the whole team, use the following commands:

$ slack trigger create --trigger-def triggers/log_run_trigger.ts
$ slack trigger create --trigger-def triggers/display_leaderboard_trigger.ts

The scheduled trigger that displays the leaderboard on a weekly cadence requires configurations for which channel to post to. This is done with environment variables and can be configured by moving .env.example to .env then adding the channel ID of a channel with you and all of your running buddies:

$ mv .env.example .env
$ slack trigger create --trigger-def triggers/display_weekly_stats.ts

Datastores

For storing data related to your app, datastores offer secure storage on Slack infrastructure. For an example of a datastore, see datastores/run_data.ts. The use of a datastore requires the datastore:write/datastore:read scopes to be present in your manifest.

Testing

For an example of how to test a function, see functions/log_run_test.ts. Test filenames should be suffixed with _test.

Run all tests with deno test:

$ deno test

Deploying Your App

Once development is complete, deploy the app to Slack infrastructure using slack deploy:

$ slack deploy

When deploying for the first time, you'll be prompted to create a new link trigger for the deployed version of your app. When that trigger is invoked, the workflow should run just as it did when developing locally (but without requiring your server to be running).

Viewing Activity Logs

Activity logs of your application can be viewed live and as they occur with the following command:

$ slack activity --tail

Project Structure

.slack/

Contains apps.dev.json and apps.json, which include installation details for development and deployed apps.

datastores/

Datastores securely store data for your application on Slack infrastructure. Required scopes to use datastores include datastore:write and datastore:read.

functions/

Functions are reusable building blocks of automation that accept inputs, perform calculations, and provide outputs. Functions can be used independently or as steps in workflows.

triggers/

Triggers determine when workflows are run. A trigger file describes the scenario in which a workflow should be run, such as a user pressing a button or when a specific event occurs.

workflows/

A workflow is a set of steps (functions) that are executed in order.

Workflows can be configured to run without user input or they can collect input by beginning with a form before continuing to the next step.

manifest.ts

The app manifest contains the app's configuration. This file defines attributes like app name and description.

slack.json

Used by the CLI to interact with the project's SDK dependencies. It contains script hooks that are executed by the CLI and implemented by the SDK.

Resources

To learn more about developing automations on Slack, visit the following:

• Automation Overview
• CLI Quick Reference
• Samples and Templates

deno-virtual-running-buddies's Issues

Add tests for functions that involve runner statistics

Due to some flaky behavior involving times with javascript and the GitHub Action that runs tests, tests for the following functions were removed in #eb2ba2b:

• collect_runner_stats
• collect_team_stats
• format_leaderboard

Here's an example of a failing run and passing run on the same commit... 😪

These tests should ideally be returned, but in a more stable state! Possibly by using defined dates and times in the test? My current hypothesis is that these tests were passing or failing based on what time the action began, but I am somewhat unsure. Something to soon explore!

Leaderboard workflow reports zero miles ran after logging a run

1. Create the Log a run trigger
2. Run the Log a run trigger
3. Create the Display Leaderboard trigger
4. Run the Display leaderboard trigger
5. Expect the leaderboard to correctly reflect the number of miles you ran

Actual result: 0 miles ran

cc @E-Zim

Running log-a-run shortcut trigger fails workflow with `parameter_validation_failed`

After I create the trigger and run locally, I see the following activity logs:

2023-05-09 11:04:05 [info] [Wf056ZU6V25S] (Trace=Tr056QRF24UE) Workflow 'Log a run' started
2023-05-09 11:04:05 [error] [Wf056ZU6V25S] (Trace=Tr056QRF24UE) Workflow 'Log a run' failed
	parameter_validation_failed - Validation for parameter `fields` failed: elements_param_validation_failed - form_input_types_validate_fail

The scheduled trigger in this application doesn't work; do we want to keep it?

I believe because the scheduled trigger definition uses trigger data like interactivity and channel that do not exist on scheduled triggers; scheduled triggers are neither interactive nor do they necessarily have an associated channel with them.

If I understand the intention of the scheduled trigger in this app, it is to post the leaderboard on a regular cadence in a channel somewhere. I think to enable this pattern, we would need to implement a "configure" workflow where a user can "configure" this scheduled trigger to post in a specific channel of their choosing. Then this workflow would dynamically create a scheduled trigger using a custom function, setting the channel chosen by the user as an input into the display leaderboard workflow.

Alternatively, can consider removing the scheduled trigger altogether.

Leaderboard workflow has errors in date math and query assembly

When I ran the leaderboard workflow today, I see this:

2023-09-21 12:57:40 [info] [Wf056QRA24UW] (Trace=Tr05TADFAYDT) Shortcut trigger successfully started execution of function 'Display the leaderboard'
2023-09-21 12:57:40 [info] [Fn056UFF79GD] (Trace=Tr05TADFAYDT) Function 'Display the leaderboard' (workflow function) started
2023-09-21 12:57:41 [info] [Wf056QRA24UW] (Trace=Tr05TADFAYDT) Workflow 'Display the leaderboard' started
2023-09-21 12:57:41 [info] [Wf056QRA24UW] (Trace=Tr05TADFAYDT) Workflow step 1 of 4 started
2023-09-21 12:57:41 [info] [Fn056ZU6R6DA] (Trace=Tr05TADFAYDT) Function 'Collect team stats' (app function) started
2023-09-21 12:57:42 [info] [Datastore:running_datastore] (Trace=Tr05TADFAYDT) Datastore query succeeded with '{"expression":"#date BETWEEN :start_date AND :end_date","expression_attributes":{"#date":"rundate"},"expression_values":{":start_date":"9\/15\/2023",":end_date":"9\/21\/2023"},"limit":100,"cursor":""}'
2023-09-21 12:57:42 [error] [Datastore:running_datastore] (Trace=Tr05TADFAYDT) Datastore query failed with '{"expression":"#date BETWEEN :start_date AND :end_date","expression_attributes":{"#date":"rundate"},"expression_values":{":start_date":"9\/8\/2023",":end_date":"9\/14\/2023"},"limit":100,"cursor":""}'
	ValidationException: Invalid FilterExpression: The BETWEEN operator requires upper bound to be greater than or equal to lower bound; lower bound operand: AttributeValue: {S:9/8/2023}, upper bound operand: AttributeValue: {S:9/14/2023}
2023-09-21 12:57:42 [error] [Fn056ZU6R6DA] (Trace=Tr05TADFAYDT) Function 'Collect team stats' (%!!(MISSING)s(<nil>) function) failed
	Failed to retrieve past runs: datastore_error
2023-09-21 12:57:43 [error] [Wf056QRA24UW] (Trace=Tr05TADFAYDT) Workflow step 'Collect team stats' failed
2023-09-21 12:57:43 [error] [Wf056QRA24UW] (Trace=Tr05TADFAYDT) Workflow 'Display the leaderboard' failed
	Failed to retrieve past runs: datastore_error
2023-09-21 12:57:43 [error] [Fn056UFF79GD] (Trace=Tr05TADFAYDT) Function 'Display the leaderboard' (%!!(MISSING)s(<nil>) function) failed
	Failed to retrieve past runs: datastore_error

The error message is correct: the following are not ordered correctly:

ValidationException: Invalid FilterExpression: The BETWEEN operator requires upper bound to be greater than or equal to lower bound; lower bound operand: AttributeValue: {S:9/8/2023}, upper bound operand: AttributeValue: {S:9/14/2023}

DynamoDB is reporting that the values being compared, start date and end date, are not ordered. Since these are stored as strings (that's what the {S:} in the error stands for), Dynamo will want these to be sorted lexicographically. This is a problem for our sample implementation because we are using American dates, which are not sorted lexicographically 😬.

So we should fix this. Dynamo recommends to use ISO-8601 date strings to store dates and times. We could use a number, too, but the nice thing about ISO strings is that they are human readable.