Configure
Use an ellipsis.yaml
file to customize how Ellipsis behaves. This will override any global settings you have configured via the web UI.
Organization config
In the web app at https://app.ellipsis.dev, you can configure these default settings across your entire organization:
- Automatically review PRs (default
true
): Should we review pull requests when published and on each new commit? - Automatically summarize PRs (default
true
): Should we summarize pull requests when published and on each new commit? - Quiet mode (default
false
): Should Ellipsis skip commenting 'Looks good to me!' when there are no issues found?
Repository config
Use an ellipsis.yaml
file in your repository root to customize how Ellipsis behaves. This will override any global settings you have configured via the web UI.
Getting Started
Here is a small example you can copy/paste. Be sure to update it for your repository!
version: 1.3
pr_review:
confidence_threshold: 0.7
rules:
- "Code should be DRY (Dont Repeat Yourself)"
- "There should no secrets or credentials in the code"
Here's an example of how we configure Ellipsis on our internal repo:
version: 1.3
about:
- "This is a codebase for a code generation tool called Ellipsis. It can review GitHub pull requests, answer questions about code, and even generate bug fixes!"
- "We're migrating away from using AWS CDK. Our infrastructure is no longer part of this repository."
# See: https://docs.ellipsis.dev/build
build:
file: "ellipsis.Dockerfile"
commands:
- name: "lint_fix"
description: "Lints the code in fix mode, which will fix some errors, format some files, and throw and error when there are violations."
command: "./scripts/lint.sh"
- name: "unit_tests"
description: "Runs the unit tests."
command: ./scripts/unit_test.sh
pr_review:
confidence_threshold: 0.7
rules:
- "Code should be DRY (Dont Repeat Yourself)"
- "There should no secrets or credentials in the code"
- "Extremely Complicated Code Needs Comments"
- "Use Descriptive Variable and Constant Names"
- "API routes must have error handling, they shouldn't intentionally return a HTTP 500"
- "Use retries when calling external API services"
- "Don't log sensitive data"
- "Follow the Single Responsibility Principle"
- "Function and Method Naming Should Follow Consistent Patterns"
General preferences
Use the about
section to give Ellipsis general information and preferences about your repo, especially anything hard for Ellipsis to discover from reading your code:
version: 1.3
about:
- "We're in the middle of migrating from X to Y, so new components should use Y."
- "Everything in `/foo/bar` is deprecated."
For reviewing PRs
You can customize how Ellipsis behaves when reviewing code by modifying the pr_review
section of your ellipsis.yaml
. Need help? Contact us.
Here's an example of a rule that says "Don't log sensitive data":
Add custom rules
Rules are natural language instructions for our code review AI.
For example, if you work with Tailwind, you might add a rule like "Always use an object to store Tailwind CSS properties instead of defining them inline". When no rules are provided we use a set of sensible defaults.
pr_review:
rules:
- "Code should be DRY (Dont Repeat Yourself)"
- "There should no secrets or credentials in the code"
Improve comment quality
Increasing the confidence_threshold
will result in fewer, but higher quality comments.
pr_review:
confidence_threshold: 0.85
Quiet mode
If quiet
mode is enabled, Ellipsis will only leave reviews when it has comments, so "Looks good to me" reviews will be skipped. This can reduce clutter.
pr_review:
quiet: true
Enable/disable automatic reviews
You can also disable automatic code review using auto_review_enabled
.
pr_review:
auto_review_enabled: false
Enable/disable automatic summaries
You can also disable automatic code summaries using auto_summarize_pr
.
pr_review:
auto_summarize_pr: false
Auto-review draft PRs
You can enable auto-review on draft PRs using auto_review_draft
.
pr_review:
auto_review_draft: true
Ignore certain base/head branches
You can disable auto-review on particular branches by specifying names (or Unix shell-style wildcards).
pr_review:
ignore:
base:
- "staging" # ignore PRs into the 'staging' branch
head:
- "test/*" # ignore PRs on branches starting with 'test/'
- "debug/*" # ignore PRs on branches starting with 'debug/'
For addressing PR comments
You can choose how Ellipsis returns code it generates while addressing comments on a PR. Choose between new_pr
or new_commit
.
version: 1.3
pr_address_comments:
delivery: "new_pr"
User specific behavior
You can add personalized configurations for each developer on the team using user_overrides
, which is at the top level of the config. Use this if you want to try out Ellipsis before enabling it for the rest of the team.
pr_review:
confidence_threshold: 0.5
rules:
- "Code should be DRY (Dont Repeat Yourself)"
- "There should no secrets or credentials in the code"
user_overrides:
- usernames: ["user1"]
rules:
- "All new functions should have docstrings."
- usernames: ["user2", "user3"]
confidence_threshold: 0.9
In this example, user1
will inherited the confidence_threshold=0.5
, but will replace the two rules; meanwhile, user2
and user3
will retain the two base rules but have their own confidence_threshold=0.9
Activate for only some users
Ellipsis calculates your active users by checking the number of seats vs. the number of users who have triggered a workflow in the last month.
If you want to enable Ellipsis for only some users, you can use the user_overrides
(see above):
pr_review:
auto_summarize_pr: false
auto_review_enabled: false
user_overrides:
- usernames: ["user1", "user2", "user3"]
auto_summarize_pr: true
auto_review_enabled: true
In this example, user1
, user2
, and user3
will be the only users to automatically get summaries and reviews.