Grit can automatically heal failing GitHub Actions tests by retrying flaky tests, running configurable shell commands, and using AI to fix simple errors.
To enable auto-healing, head to your project's page and select the "Testing" tab. First, enable healing for your pull requests by flipping the "User Settings" toggle:
Failing workflows will only be healed if:
- Healing that workflow is enabled in the repository settings.
- The author of the pull request has enabled healing for their pull requests.
Activating auto-healing does not immediately apply to all developers on a repository. Instead, each developer must enable it through the Grit app to allow Grit to heal their pull requests. This allows you to gradually roll out the feature to your team.
Auto-healing is always enabled for Grit-generated pull requests, as it substantially improves the success rate of pull requests. We therefore recommend configuring auto-healing even if you don't plan to use it for your own pull requests.
Test settings allow you to configure per-workflow healing strategies. Grit uses AI to attempt to heal workflows, but you can also provide specific shell commands to run before retrying a workflow.
Typically, a workflow corresponds to a YAML file in your repository's
Three different healing strategies are available:
- AI healing. This is the default strategy and is intended for simple linting or test errors that can be fixed with limited intelligence. If there are too many errors or errors are too complex, this strategy will not commit a fix.
- Custom shell commands. You can add any number of custom shell commands as part of a workflow's healing strategy. These commands run on the failing commit from the repository root. These are particularly useful for automatically fixing linting errors or running code formatters.
- Rerun. This helps with flaky tests. It will re-run all failed jobs in a workflow.
For example, the following configuration attempts to fix linting errors in a project with TypeScript and Rust components:
Strategies can be reordered using drag and drop. In order to improve performance, shell commands are run consecutively on one clone of the repository, and so they are treated as one group when reordering.