Sleuth's Custom Automation Framework Deep-Dive: Actions

How often have you done something manual that took a large part of your day and thought to yourself “there has to be some way to automate this”? Usually “this” is a task, or a set of tasks, that you have to do over and over again.

A scenario like this is exactly what is addressed by the final part of the Sleuth’s Custom Automation Framework article series: actions.

What Are Actions?

The actions portion of any Sleuth Automation can be thought of the "just do it" step. Actions are responsible to actually doing something and this means all of the hard work we have covered during this series when it comes to understanding triggers, conditions, and (optionally) filters has led us to this moment where we can learn about what type of tasks can actually be automated.

Where triggers help us determine when and Sleuth Automation should happen, conditions help us define what should be true to execute the automation, filters help us narrow down which items in a larger list the Sleuth Automation should affect, the action is what actually should be done by the automation.

Want to post a message to a Slack channel? That’s an action.

Want to add a label to a pull request in GitHub? That’s an action.

Want to automatically push changes from staging to production without manually pressing a button? That’s an action.

The power of Sleuth’s Custom Automations framework, and the part where actions play a critical role, comes from the varying array of different tools that can be interacted with. Sleuth is a tool that sits in a central location across how your team delivers software by connecting to your:

• git repositories (GitHub, Gitlab, BitBucket, Azure DevOps)
• CI/CD tools (Jenkins, CircleCI, Buildkite, and the pipelines provided by git providers)
• Issue tracker (Jira, Linear, etc.)
• Incident management (PagerDuty, OpsGenie, ServiceNow, etc.)
• Observability (DataDog, New Relic, CloudWatch, Sentry, etc.)
• Communication tools (Slack or MS Teams)

This means that Sleuth can see something in your git repo (e.g. a pull request of a particular type), connect it to a particular issue in your issue tracker, and then use an action to update either the pull request or the issue based on some event.

Types of Actions

A full list of all of the available Actions section of the Sleuth Actions Documentation, but to give an idea of what type of things can be done with Sleuth’s Custom Automation framework here are some different types of actions:

Notifications

Notification Actions can post messages in Slack or MS Teams a fully customized message to fit any requirements. Messages can be sent to channels or individuals.

This can even take the next step of adding a threaded message to the original message, letting users keep their messages and notifications organized and clean

There is also the option to listen to reactions to a message and trigger follow-up actions based on enough reactions to a message.

Issues

For any connected issue in your issue tracker a Sleuth action can do a couple of things.

An action can automatically comment on an issue, which can let the product team be aware of when changes have deployed to a particular environment by adding a comment and linking to the connected code changes.

Sleuth can also automatically move an issue from one state to the next like updating an issue state from “in development” to “deployed”.

With both of these you are able to automatically keep your issue tracker in sync with the work your development team is doing - all without requiring developers to manually add comments or move issues around!

Pull Requests

When it comes to pull requests Sleuth Actions can manage pull requests on your behalf, including:

• Add or remove pull request labels - this can help organize your pull requests automatically, or even highlight when certain pull requests are becoming too complex
• Add a comment to a pull request - super useful in scenarios where development teams use pull requests as their source of truth and you want to keep everyone updated on when changes in said pull request have landed in production
• Close a pull request - automatically close a pull request based on some criteria, like draft pull requests that have not been interacted with in some time

And More!

The above list is not exhaustive, just a summary of what types of actions are available. For a full and detailed list head on over to the Sleuth Actions Documentation.

Action Variables

Most Actions within Sleuth’s Custom Automation framework can simply be listed in a Sleuth Automation without any additional configuration. However, there are many scenarios, especially when we are posting messages in Slack or MS Teams channels, where we want to not only provide a string representing the information that we want to post, but we also want to include specific information from the item(s) affected by the Sleuth Automation.

To help with this Sleuth offers a large list of action variables, which includes things like:

• Author(s) of a deployment, along with timestamps of when the deployment occurred
• Variables for the various stages that make up Change Lead Time (one of the four DORA metrics); coding_time, pr_review_lag_time, pr_review_time, and deploying_time
• Variables related to any Goals set for Change Lead Time (e.g. keeping review time under 10 hours)
• A summary of all (or a filtered list of) open pull requests found under Work in Progress

And many, many more. Definitely keep the list of available action variables handy!

Examples of Actions

Two Sleuth actions that can be used together is the ability to comment on a related issue, as well as move the related issue from one state to another. In this example Sleuth can automatically detect any mentioned Jira issues within any commits or pull requests in the current deploy.

With this information in hand when the deploy reaches the production environment, a Sleuth Automation can use notify_mentioned_issue to add a comment on the related Jira issue, then use transition_mentioned_issues to transition the issue from in development to deployed.

The example above means developers never need to leave their IDE or GitHub while still keeping the rest of the business up-to-date on the status of issues. Less context switching and less distractions, letting the developer jump to the next task instead of manually updating a Jira board.

This is just one example. The Sleuth Automations Marketplace, which contains a curated list of Sleuth Automations built using the YAML framework that has been discussed here, is another great resource for examples that are available out-of-the box.

For further inspiration there is also the Sleuth Automations Cookbook documentation article.

Automate All the Things

Now that we have an idea of the possibility of what can be Automated thanks to Actions we have made it through all parts of Sleuth’s Custom Automation framework.

This rich YAML framework is what has been used to build all of the curated Sleuth Automations found in the Sleuth Automation Marketplace. While this series may have already planted some seeds of ideas for automation, navigating through the available Sleuth Automations can give some additional inspiration! As a bonus, any existing Sleuth Automation has a dedicated YAML tab that can be used to copy and paste any YAML to get a head start on any Custom Automation.

Lastly, as a reference here is the Sleuth's Custom Automation Framework Deep-Dive Series overview article that you can bookmark for future adventures with Custom Automations.

Happy automating!