Skip to main content
Quality gates can be configured at the repository level using a configuration file. This allows teams to version control their quality standards alongside their code and override organization-level settings when needed.

Setup

1. Create Quality Gates Configuration File

Create a quality_gates_conditions.json file in the .codeant folder in your repository root:

2. Define Quality Gate Conditions

The quality_gates_conditions.json file allows you to specify quality gate conditions that will be enforced for your repository, taking full precedence over organization or repository database configurations.

Configuration Format

Configuration Options

  • enabled (boolean | null, required): Controls whether quality gates are active for this repository
    • true: Enable quality gates with the defined conditions
    • false: Disable all quality gates for this repository
    • null: Inherit quality gate settings from the organization (repository-level only)
  • conditions (array, required when enabled): List of quality gate conditions to enforce
  • metric (string): The code quality metric to monitor
  • operator (string): Comparison operator for the condition. Available operators depend on the metric type (see Operator Constraints below)
    • "LESS_THAN": Value must be less than threshold
    • "GREATER_THAN": Value must be greater than threshold
    • "EQUALS": Value must equal threshold
    • "LESS_THAN_OR_EQUALS": Value must be less than or equal to threshold
    • "GREATER_THAN_OR_EQUALS": Value must be greater than or equal to threshold
  • value (string): The threshold value for comparison. For most metrics this is a numeric string (e.g., "80"). For security rating metrics, this is a letter grade (e.g., "A", "B", "C")
  • scope (array): Where the condition applies
    • "commit": Apply to individual commits
    • "pull_request": Apply to pull requests
    • Can specify both: ["commit", "pull_request"]
  • exclude_files (array, optional): File patterns to exclude from this quality gate check (e.g., ["tests/**", "*.test.js", "docs/**"])

Available Metrics

New Coverage Percentage

Fails the quality gate when new code coverage falls below the specified percentage. Only applies to newly added or modified code.

Total Coverage Percentage

Fails the quality gate when total code coverage across the entire codebase falls below the specified percentage.

New Secrets Pushed

Fails the quality gate if any new secrets (API keys, passwords, tokens, etc.) are detected in the code. This metric automatically uses GREATER_THAN 0 - no custom operator or value is needed.

Duplicated Lines Density

Fails the quality gate when the percentage of duplicated lines in new code exceeds the specified threshold.

SAST Security Rating

SAST (Static Application Security Testing) ratings use letter grades based on the highest severity issue found:
Fails the quality gate when the SAST security rating is worse than the specified grade. In this example, the gate fails if the rating is B or worse (i.e., requires rating A or better).

SCA Security Rating

SCA (Software Composition Analysis) ratings use letter grades based on the highest severity vulnerability found in dependencies:
Fails the quality gate when the SCA security rating is worse than the specified grade. In this example, the gate fails if the rating is C or worse.

IaC Security Rating

IaC (Infrastructure as Code) ratings use letter grades based on the highest severity issue found in infrastructure configurations:
Fails the quality gate when the IaC security rating is worse than the specified grade.

Operator Constraints

Not all operators are available for every metric. The table below shows which operators can be used with each metric type:

Sample Configuration

Comprehensive Quality Configuration

Configuration with File Exclusions

Inherit Organization Settings

Use this configuration to inherit quality gate settings from the organization level. This is the default behavior when no repository-level configuration exists.

Disabled Quality Gates

Use this configuration to completely disable quality gates for a specific repository, even if they’re enabled at the organization level.

Configuration Precedence

Quality gate settings follow a specific precedence hierarchy:
  1. Repository Configuration File (Highest Priority)
    • If .codeant/quality_gates_conditions.json exists in the repository, its settings take full precedence
    • A repository file with "enabled": false disables quality gates for that repository
    • All conditions defined in the file override any organization or repository database settings
  2. Repository Database Settings (Medium Priority)
    • Explicit repository-level settings in the database or S3
    • Used when no repository configuration file exists
  3. Organization Settings (Lowest Priority)
    • Organization-level default settings
    • Applied to repositories that have no repository-specific configuration
Example Scenarios:
  • Repo file exists with enabled: true → Uses conditions from repo file only
  • Repo file exists with enabled: false → Quality gates disabled, ignores all other settings
  • Repo file exists with enabled: null → Inherits quality gate settings from the organization
  • No repo file, repo DB has settings → Uses repo DB settings
  • No repo file, no repo DB settings → Inherits from organization settings

How It Works

  1. File Detection: CodeAnt AI automatically detects the quality_gates_conditions.json file in your .codeant/ directory
  2. Configuration Loading: When a commit or pull request is created, CodeAnt loads the quality gates configuration in precedence order
  3. Condition Evaluation: Each defined condition is evaluated against the code analysis results
  4. Gate Status:
    • Pass: All conditions meet their thresholds
    • Fail: One or more conditions don’t meet their thresholds
  5. Integration: Results are reported to your Git provider as status checks on commits and pull requests

Best Practices

  • Version Control: Store the configuration file in your repository so changes are tracked and reviewed
  • Team Consensus: Discuss and agree on quality thresholds with your team before implementing
  • Start Conservative: Begin with relaxed thresholds and gradually tighten as code quality improves
  • Security First: Prioritize security metrics over quality metrics
  • Document Exceptions: If disabling quality gates, document the reason in your team’s documentation
  • Regular Review: Periodically review and adjust thresholds as your codebase and team standards evolve
  • Test Changes: Test configuration changes in a feature branch before applying to main branches
Once configured, quality gates will automatically enforce your standards on every commit and pull request, ensuring consistent code quality across your team.