April 2024 Summaries

Sleuth's Custom Automation Framework is designed to automate manual work, set up guardrails and best practices for teams, and keep members informed throughout the software delivery process. The framework is service-agnostic, allowing it to work with various tools such as GitHub, Bitbucket, Gitlab, Azure DevOps, Jira, Linear, DataDog, and PagerDuty. Custom Sleuth Automations are built on a YAML-based rules engine, which includes trigger, condition, filter, and action building blocks. Users can leverage the Marketplace for pre-built automations or create their own by adding a rules.yml file to their repositories.

Sleuth's Custom Automation Framework enhances workflow automation by utilizing triggers to specify when an automation should be executed. These triggers, which form a crucial part of the framework, include categories such as deploy, pull request, CRON, and Work in Progress (WIP), each offering specific events to initiate automations. Deploy triggers activate based on deployment events and their durations, while pull request triggers respond to actions involving pull requests, such as opening, editing, or merging. CRON triggers allow automations to be scheduled at regular intervals for teams, projects, or open pull requests, and WIP triggers focus on open pull requests to provide insights into ongoing work and its impact on DORA metrics. This system streamlines processes by facilitating automations that can react to a variety of conditions, thereby improving efficiency and focus for development teams. The series will continue with a discussion on conditions, which define the specific checks necessary to ensure automations are triggered appropriately.

The text discusses the concept of conditions in Sleuth's Custom Automation Framework. Conditions are used to specify when an automation should run, allowing developers to narrow down their automations to specific situations. A condition is defined using a variable, operator, and value pattern. Various types of condition variables include Deploy-Based Variables, Pull Request-Based Variables, Time-Based Variables, and Work in Progress-Based Variables. Condition operators are also discussed, which allow developers to specify the relationship between the variable and its value. The text provides examples of conditions and explains how they can be used to automate specific tasks under certain circumstances.

The article discusses filters in Sleuth Automation framework, which are used with sets of Work in Progress Items or pull requests. Filters follow a pattern of variable -> operator -> value and are applied to each item in a set. They differ from conditions as the latter is applied to individual deploys/pull requests/WIP items or the whole set of WIP items/pull requests. Sleuth Automation filters share variables and operators with conditions, such as coding_time, deploying_time, pr_is_draft, and pr_is_ignored. The article provides an example of using filters in a Custom Sleuth Automation that notifies when the deploying time for a merged pull request exceeds a limit.

The text discusses actions, which are a crucial part of the Sleuth's Custom Automation Framework. Actions are responsible for performing tasks in an automated process. They follow triggers, conditions, and filters that determine when, what, and how to automate. Various types of actions include notifications, issue management, pull request management, and more. Action variables provide specific information from the affected items during automation. Examples of actions include automatic comments on related Jira issues and transitioning an issue from one state to another. The Sleuth Automations Marketplace offers a curated list of pre-built automations using this framework.