Repository Rules Configuration
What are Repository Rules?
Repository rules are loaded every time GitAuto starts working on your repository. They control how tests are generated, ensuring consistent code quality across all your projects.
The rules page has many options, but this guide explains what each one actually does, why the defaults are recommended, and how to use them effectively.
Repository Rule Categories
Jump to any section that interests you:
- Edit Scope- Restrict the agent to test files only
- Comment Rules- Configure comment generation preferences for GitAuto-generated code
- Test File Location and Naming Rules- Configure test file placement and naming conventions
- Test Constants Rules- Configure test constants management
- Unit Test Rules- Configure unit test generation preferences
- Component Test Rules- Configure component test preferences (React, Vue, etc.)
- Custom Repository Rules- Free-form rules
- Output Language- Configure the language for comments (separate page)
- GITAUTO.md- Repo-level rules learned from feedback (separate page)
Edit Scope
Controls whether the agent is allowed to modify implementation files in this repository. By default the agent can edit any file. When the toggle is off, the agent is restricted to test files only.
When On (default)
The agent can edit any file the iteration discovers it needs to change. ESLint flags dead code (no-unreachable, no-unnecessary-condition); the agent removes it; coverage reaches 100%.
When Off
The file-modify tools reject any path that is not a test file. If a coverage gap is caused by dead code in an implementation file the agent cannot remove, the gap is accepted and the iteration finishes — the runtime accepts <100% coverage in this case rather than looping forever.
Use this for repositories where humans own the implementation and the agent is expected to add tests around existing behavior.
Comment Rules
Comments in Generated Code
Comments are disabled by default. Clean code should be self-explanatory. Enable only for complex algorithms that need explanation.
function calculateTax(amount: number, rate: number): number {
if (amount <= 0) return 0;
if (rate < 0 || rate > 1) return 0;
return amount * rate;
}/**
* Calculates tax amount based on base amount and tax rate
* @param amount - Base amount to calculate tax for
* @param rate - Tax rate (0-1)
* @returns Calculated tax amount
*/
function calculateTax(amount: number, rate: number): number {
// Validate amount is positive
if (amount <= 0) return 0;
// Validate rate is between 0 and 1
if (rate < 0 || rate > 1) return 0;
// Calculate and return tax
return amount * rate;
}Test File Location and Naming
Test File Placement
Test files are placed next to source files by default. This makes it immediately obvious what's tested and what isn't.
src/
├── components/
│ ├── Button.tsx
│ ├── Button.test.tsx
│ ├── Modal.tsx
│ └── Modal.test.tsx
├── utils/
│ ├── formatDate.ts
│ ├── formatDate.test.ts
│ ├── validateEmail.ts
│ └── validateEmail.test.tssrc/
├── components/
│ ├── Button.tsx
│ └── Modal.tsx
├── utils/
│ ├── formatDate.ts
│ └── validateEmail.ts
└── tests/
├── components/
│ ├── Button.test.tsx
│ └── Modal.test.tsx
└── utils/
├── formatDate.test.ts
└── validateEmail.test.tsTest Naming Conventions
Choose a specific naming convention rather than auto-detect for consistency and stability. Auto-detection can be unpredictable when your project has mixed patterns.
# JavaScript/TypeScript
Button.tsx → Button.test.tsx
utils.js → utils.spec.js
# Python
auth.py → test_auth.py
utils.py → test_utils.py
# Go
auth.go → auth_test.go
utils.go → utils_test.go
# Java
Auth.java → AuthTest.java
Utils.java → UtilsTest.java
# Ruby
auth.rb → auth_spec.rb
utils.rb → utils_spec.rbTest Constants Rules
Test Constants Management
Use centralized constants when you have many shared test objects across multiple files.
// If GitAuto finds this pattern in existing tests:
const MOCK_USER = {
id: 1,
email: 'test@example.com',
name: 'Test User'
};
// It will use the same pattern in new tests
const MOCK_PRODUCT = {
id: 1,
name: 'Test Product',
price: 99.99
};// tests/constants.ts
export const MOCK_USER = {
id: 1,
email: 'test@example.com',
name: 'Test User'
};
export const MOCK_PRODUCT = {
id: 1,
name: 'Test Product',
price: 99.99
};
// user.test.ts
import { MOCK_USER } from '../tests/constants';Unit Test Rules
Function Style vs Class Style
Function style is preferred because functional patterns are easier to test and reason about.
describe('calculateDiscount', () => {
it('should return 0 when amount is 0', () => {
expect(calculateDiscount(0, 0.1)).toBe(0);
});
it('should calculate 10% discount correctly', () => {
expect(calculateDiscount(100, 0.1)).toBe(10);
});
});class CalculatorTest {
testCalculateDiscountWithZeroAmount() {
expect(calculateDiscount(0, 0.1)).toBe(0);
}
testCalculateDiscountWithValidInput() {
expect(calculateDiscount(100, 0.1)).toBe(10);
}
}Comprehensive Test Coverage
Tests edge cases and error conditions where most bugs hide, preventing production issues.
describe('validateEmail', () => {
// Happy path
it('should return true for valid email', () => {
expect(validateEmail('user@example.com')).toBe(true);
});
// Edge cases
it('should return false for email without @', () => {
expect(validateEmail('userexample.com')).toBe(false);
});
it('should return false for empty string', () => {
expect(validateEmail('')).toBe(false);
});
it('should return false for null input', () => {
expect(validateEmail(null)).toBe(false);
});
// Boundary conditions
it('should handle very long email addresses', () => {
const longEmail = 'a'.repeat(100) + '@example.com';
expect(validateEmail(longEmail)).toBe(true);
});
});Allow Source Code Refactoring
Sometimes source code structure makes it difficult to write clean tests. Small refactoring improves both code and test quality.
function validateAndSaveUser(userData) {
// Hard to test: validation and database mixed together
if (!userData.email || !userData.email.includes('@')) {
throw new Error('Invalid email');
}
if (!userData.name || userData.name.length < 2) {
throw new Error('Invalid name');
}
// Database call mixed with validation logic
const existingUser = database.findByEmail(userData.email);
if (existingUser) {
throw new Error('User already exists');
}
const user = {
id: generateId(),
email: userData.email.toLowerCase(),
name: userData.name.trim(),
createdAt: new Date()
};
database.save(user);
return user;
}// validate-user-data.ts
export function validateUserData(userData) {
if (!userData.email || !userData.email.includes('@')) {
throw new Error('Invalid email');
}
if (!userData.name || userData.name.length < 2) {
throw new Error('Invalid name');
}
}
// create-user.ts
export function createUser(userData) {
return {
id: generateId(),
email: userData.email.toLowerCase(),
name: userData.name.trim(),
createdAt: new Date()
};
}
// validate-and-save-user.ts
import { validateUserData } from './validate-user-data';
import { createUser } from './create-user';
export function validateAndSaveUser(userData, userRepository) {
validateUserData(userData);
const existingUser = userRepository.findByEmail(userData.email);
if (existingUser) {
throw new Error('User already exists');
}
const user = createUser(userData);
userRepository.save(user);
return user;
}Component Test Rules
Function vs Class Components
Function components with hooks are simpler and easier to test than class components.
import { render, screen } from '@testing-library/react';
import Button from './Button';
describe('Button', () => {
it('should render with correct text', () => {
render(<Button>Click me</Button>);
expect(screen.getByText('Click me')).toBeInTheDocument();
});
it('should call onClick when clicked', () => {
const handleClick = jest.fn();
render(<Button onClick={handleClick}>Click me</Button>);
screen.getByText('Click me').click();
expect(handleClick).toHaveBeenCalledTimes(1);
});
});Component Isolation
Unit tests should test one component at a time. Mocking dependencies ensures failures point to the specific component being tested.
import { render, screen } from '@testing-library/react';
import UserProfile from './UserProfile';
import * as userService from '../services/userService';
// Mock external dependencies
jest.mock('../services/userService');
const mockUserService = userService as jest.Mocked<typeof userService>;
describe('UserProfile', () => {
beforeEach(() => {
mockUserService.fetchUser.mockResolvedValue({
id: 1,
name: 'John Doe',
email: 'john@example.com'
});
});
it('should display user name when loaded', async () => {
render(<UserProfile userId={1} />);
expect(await screen.findByText('John Doe')).toBeInTheDocument();
});
});Custom Repository Rules
The free-form rules section is where you add project-specific requirements that aren't covered by the structured options. This is often the most important part of your configuration.
## Repository Context
This is a financial trading platform with real-time market data processing.
## Test-Critical Requirements
- All monetary calculations must use BigDecimal, never floating point numbers
- Test data must use realistic market scenarios: bull market, bear market, flash crash
- Mock external APIs with realistic latency delays (50-200ms) to catch timing issues
- Always test edge cases: market closed, connection timeout, invalid ticker symbols
## Domain-Specific Testing
- Price movements: test with actual historical data patterns
- User portfolio tests: include margin calls, stop-loss triggers
- Integration tests must handle market data feed interruptions gracefullyGITAUTO.md - Automatic Learning
Both Repository Rules and GITAUTO.md are repo-specific. The difference is who writes them: the rules on this page are yours - GitAuto reads them but never modifies them. GitAuto can automatically learn from reviewer feedback and CI failures, persisting reusable lessons in a GITAUTO.md file at your repo root. GITAUTO.md is a git-managed file that both you and GitAuto can edit. See the GITAUTO.md documentation for details.
How Repository Rules Are Applied
Rules are loaded fresh every time GitAuto starts working on your repository. This means changes take effect immediately for new test generation tasks.
Getting Started
1. Start with Defaults
The default settings work well for most projects. Go to your Rules Settings and see what's already configured.
2. Add Project Context
Use the free-form section to explain your project setup, tech stack, and any specific requirements. This helps GitAuto understand your codebase better.
3. Test and Refine
Create a test PR to see how GitAuto applies your rules. Adjust the configuration based on the results. Rules are meant to be iterative - you'll refine them as you learn what works best for your project.
Need Help?
Want a rule that doesn't exist? Use the free-form section to write exactly what you need. GitAuto is flexible and can follow detailed instructions. Have questions about configuration? We're here to help you get the most out of GitAuto's rules system.
Contact us with your questions or suggestions for new structured rules.