# Contributing to Apiforge

Thank you for your interest in contributing to Apiforge! This document provides guidelines and information for contributors.

## Getting Started

### Prerequisites

- Rust 1.91.1 or later (project MSRV; see `rust-version` in Cargo.toml)
- Docker (for building and testing container features)
- kubectl and a Kubernetes cluster (for testing K8s features)
- AWS CLI (optional, for ECR features)

### Building

```bash
git clone https://github.com/PrazwalR/Apiforge.git
cd Apiforge
cargo build
```

### Running Tests

```bash
cargo test
```

## Development Guidelines

### Code Style

- Follow standard Rust formatting (`cargo fmt`)
- Run `cargo clippy` before committing
- Add documentation comments for public APIs
- Keep functions focused and small

### Commit Messages

Use conventional commit format:
- `feat:` New features
- `fix:` Bug fixes
- `docs:` Documentation changes
- `refactor:` Code refactoring
- `test:` Adding or modifying tests
- `chore:` Maintenance tasks

Example: `feat: add retry logic for AWS operations`

### Pull Requests

1. Fork the repository
2. Create a feature branch (`git checkout -b feature/amazing-feature`)
3. Make your changes
4. Run tests and linting
5. Commit with clear messages
6. Push to your fork
7. Open a Pull Request

### PR Checklist

- [ ] Code compiles without warnings
- [ ] All tests pass
- [ ] New features have tests
- [ ] Documentation is updated
- [ ] CHANGELOG is updated (if applicable)

## Architecture Overview

Apiforge uses a step-based architecture:

```
src/
├── steps/           # Individual release steps
│   ├── git/         # Git operations (commit, push, tag)
│   ├── docker/      # Docker build and push
│   ├── kubernetes/  # K8s deployment updates
│   ├── github/      # GitHub releases
│   └── health/      # Health checks
├── integrations/    # External service clients
│   ├── aws.rs       # AWS ECR/STS
│   ├── github.rs    # GitHub API
│   └── kubernetes.rs # Kubernetes client
├── orchestrator/    # Pipeline execution and rollback
├── config.rs        # Configuration parsing
├── error.rs         # Error types
└── utils/           # Shared utilities
```

### Adding a New Step

1. Create a new module in `src/steps/`
2. Implement the `Step` trait:
   - `name()` - Step identifier
   - `description()` - Human-readable description
   - `validate()` - Pre-execution validation
   - `execute()` - Main step logic
   - `dry_run()` - Simulation mode
   - `rollback()` - Undo on failure (optional)

3. Register in `src/steps/mod.rs`

### Error Handling

- Use the custom `Result<T>` type from `src/error.rs`
- Create specific error variants for clear diagnostics
- Wrap external errors with context

## Reporting Issues

When reporting bugs:
- Describe expected vs actual behavior
- Include Apiforge version (`apiforge --version`)
- Provide relevant configuration (redact secrets)
- Include error messages and logs

## Feature Requests

Open an issue with:
- Clear description of the feature
- Use case and motivation
- Proposed implementation (optional)

## Questions?

Open a GitHub Discussion for questions or ideas that aren't bugs or feature requests.

## License

By contributing, you agree that your contributions will be licensed under the MIT License.
