Skip to main content

Configure

TLDR:

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": img alt

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.