Thank you for your interest in contributing to Aurora! This document provides guidelines and instructions for contributing to the project.
- Code of Conduct
- Getting Started
- Development Setup
- How to Contribute
- Branch Naming Convention
- Pull Request Process
- Code Style Guidelines
- Testing
- Reporting Bugs
- Suggesting Enhancements
This project adheres to a Code of Conduct that all contributors are expected to follow. Please read CODE_OF_CONDUCT.md before contributing.
Aurora is a natural-language interface for managing cloud infrastructure. Before contributing, familiarize yourself with:
- The README.md for project overview
- The AGENTS.md for agent-specific guidelines
- The documentation site for additional documentation
- Docker and Docker Compose >= 28.x
- Node.js >= 18.x (for frontend development)
- Python >= 3.12 (for backend development)
- Make (for using Makefile commands)
-
Fork the repository
- Go to https://github.com/Arvo-AI/aurora
- Click the "Fork" button in the top right
- This creates a copy under your GitHub account
-
Clone your fork
git clone https://github.com/YOUR-USERNAME/aurora.git cd aurora -
Add upstream remote
git remote add upstream https://github.com/Arvo-AI/aurora.git
-
Initialize configuration
make init
This generates secure secrets automatically.
-
Edit .env and add your LLM API key
Get one from https://openrouter.ai/keys or https://console.anthropic.com/settings/keys
nano .env # Add OPENROUTER_API_KEY=sk-or-v1-... or ANTHROPIC_API_KEY=sk-ant-... -
Start Aurora in development mode
make dev
Development mode includes hot reloading for both frontend and backend changes.
-
Get Vault root token and add to .env
Check the vault-init container logs for the root token:
docker logs vault-init 2>&1 | grep "Root Token:"
Copy the root token value and add it to your .env file:
nano .env # Add VAULT_TOKEN=hvs.xxxxxxxxxxxxxxxxxxxxxxxxxxxx -
Restart Aurora to load the Vault token
make down make dev
-
Access the application
- Frontend: http://localhost:3000
- REST API: http://localhost:5080
- Chatbot WebSocket: ws://localhost:5006
-
Stop the environment
make down
Before starting new work, sync your fork with the upstream repository:
git fetch upstream
git checkout main
git merge upstream/main
git push origin mainWe welcome various types of contributions:
- Bug fixes
- New features
- Documentation improvements
- Performance improvements
- Test coverage improvements
- Code refactoring
- Check the issue tracker to see if your issue/feature is already being discussed
- For major changes, open an issue first to discuss your proposed changes
- Make sure your fork is up to date with the upstream repository
- Create a feature branch from
mainin your fork
Use the following prefixes for your branch names:
feature/- New features or enhancements- Example:
feature/add-aws-cost-optimization
- Example:
bugfix/- Bug fixes- Example:
bugfix/fix-gcp-auth-error
- Example:
hotfix/- Urgent fixes for production issues- Example:
hotfix/security-patch-vault
- Example:
docs/- Documentation updates- Example:
docs/update-kubernetes-guide
- Example:
refactor/- Code refactoring without behavior changes- Example:
refactor/cleanup-db-utils
- Example:
test/- Adding or updating tests- Example:
test/add-connector-tests
- Example:
chore/- Maintenance tasks, dependency updates- Example:
chore/update-dependencies
- Example:
Branch names should be lowercase and use hyphens to separate words.
-
Update your fork
git fetch upstream git checkout main git merge upstream/main
-
Create a feature branch
git checkout -b feature/your-feature-name
-
Make your changes
- Write clear, concise commit messages
- Follow the code style guidelines below
- Add tests if applicable
- Update documentation as needed
-
Test your changes
# Test development build make dev -
Commit your changes
git add . git commit -m "Add feature: your feature description"
-
Push to your fork
git push origin feature/your-feature-name
-
Open a Pull Request
- Go to the main Aurora repository on GitHub
- You should see a prompt to create a PR from your recently pushed branch
- Click "Compare & pull request"
- Ensure the PR is targeting the
mainbranch of the upstream repository - Fill out the PR template with:
- Clear description of changes
- Related issue numbers (if applicable)
- Screenshots (for UI changes)
- Testing steps
-
Address review feedback
- Respond to reviewer comments
- Make requested changes in your local branch
- Push additional commits to your fork (they'll appear in the PR automatically)
git add . git commit -m "Address review feedback" git push origin feature/your-feature-name
-
PR Approval and Merge
- PRs require approval from maintainers
- Once approved, a maintainer will squash-merge your PR to
main - You can then delete your feature branch
-
Sync your fork after merge
git checkout main git fetch upstream git merge upstream/main git push origin main git branch -d feature/your-feature-name # Delete local branch git push origin --delete feature/your-feature-name # Delete remote branch
- Use kebab-case for URLs and file names
- Keep functions small and focused
- Avoid deep nesting
- Write self-documenting code
- Add comments for complex logic only
- No commented-out code in PRs
- No emojis in code or logs
Run linters before submitting:
# Frontend linting
cd client && npm run lint
When reporting bugs, please include:
- Description: Clear description of the bug
- Steps to Reproduce: Detailed steps to reproduce the issue
- Expected Behavior: What you expected to happen
- Actual Behavior: What actually happened
- Environment:
- OS and version
- Docker version
- Browser (for frontend issues)
- Relevant configuration from
.env
- Logs: Relevant error messages or logs
- Screenshots: If applicable
Use the issue tracker with the bug label.
We welcome feature suggestions! Please include:
- Use Case: Describe the problem you're trying to solve
- Proposed Solution: Your suggested approach
- Alternatives: Other solutions you've considered
- Additional Context: Any other relevant information
Open an issue with the enhancement label.
When adding new environment variables:
- Add them to
.env.examplewith documentation - Update relevant docker-compose files
- The CI pipeline will automatically validate env var consistency
- Always update both
docker-compose.yamlanddocker-compose.prod-local.yml - Keep environment variables in sync between Docker Compose files
If you have questions about contributing:
- Open a discussion on GitHub
- Contact the maintainers: info@arvoai.ca
- Check existing issues and documentation
By contributing to Aurora, you agree that your contributions will be licensed under the Apache License 2.0. See LICENSE for details.
Thank you for contributing to Aurora!