GitHub Actions Deployment Protection Rules
GitHub Actions Deployment Protection Rules are an automatic gating mechanism in your Actions workflows. In addition to gating mechanisms (like manual approvals), any GitHub App can provide deployment protection rules that make decisions automatically within your deployment workflows.
The Honeycomb Deployment Protection Rule allows you to block deployments based on the results of any supported Honeycomb query. That means you can use just about any bit of gathered telemetry to provide feedback on whether it is safe to deploy to a specific environment. That feedback mechanism isn’t intended to replace your pre-deploy CI checks. Rather, it’s a complementary and additional layer of protection that can help you catch real-time performance issues that might otherwise slip through CI unnoticed.
How it works
The Honeycomb Deployment Protection Rule mimics the same Honeycomb workflows you already use, so there’s very little to learn. Query functionality is decoupled from the Honeycomb UI and its configuration lives inside your code repo. Queries also operate with the same mechanism as Honeycomb Triggers. There’s very little that’s new to learn. If you’ve written a Honeycomb query and used a Trigger before, you know most of what you need to make our Deployment Protection Rule work.
As a developer, you control deployments by defining a query payload (the query, a threshold, and an operator) in a .honeycomb.yml file within your repo. When a deployment is requested, the GitHub App picks the appropriate query payload for the target GitHub Actions environment, sends it to Honeycomb to run, and waits for a response. After the query results return (typically within a few seconds), Honeycomb will then send back a pass or fail response to the App.
When a build initiates a deploy, the Honeycomb Deployment Protection Rule checks if it should proceed by running the query defined in the .honeycomb.yml file within your repo. The deploy proceeds if the check passes or stops if the check fails.