Thank you for your interest in contributing to Assist TEE! This document provides guidelines and information for contributors.
- Go 1.21+
- Docker 24.0+ with Docker Compose
- gVisor runtime (runsc) for production testing (Linux only)
- PostgreSQL 16+ (or use Docker Compose)
-
Clone the repository
git clone https://github.com/your-org/assist-tee.git cd assist-tee -
Build the services
make build
-
Start development environment
make run-dev # Uses docker-compose.dev.yml (no gVisor) -
Run tests
cd services/api && go test ./...
- Check existing issues to avoid duplicates
- Use the bug report template
- Include steps to reproduce, expected behavior, and actual behavior
- Include your environment details (OS, Docker version, Go version)
- Open an issue with the feature request template
- Describe the use case and why it would be valuable
- Be open to discussion about implementation approaches
- Fork the repository and create a branch from
main - Make your changes following the code style guidelines below
- Write tests for new functionality
- Update documentation if needed
- Run the test suite to ensure nothing is broken
- Submit a pull request with a clear description
- Follow standard Go conventions and
gofmt - Use meaningful variable and function names
- Add comments for exported functions
- Keep functions focused and reasonably sized
- Handle errors explicitly
// Good
func (e *DockerExecutor) SetupEnvironment(ctx context.Context, req *models.SetupRequest) (*models.Environment, error) {
// ...
}
// Avoid
func setup(r *models.SetupRequest) *models.Environment {
// ...
}- Use TypeScript types where possible
- Prefer
constoverlet - Use async/await over raw promises
- Use clear, descriptive commit messages
- Start with a verb in present tense: "Add", "Fix", "Update", "Remove"
- Keep the first line under 72 characters
- Reference issues when applicable: "Fix #123"
Add streaming output for execution logs
- Use io.MultiWriter to log stdout/stderr line-by-line
- Include environment and execution IDs in log context
- Improves debugging visibility during execution
assist-tee/
├── services/
│ ├── api/ # Go API service
│ │ ├── cmd/api/ # Entry point
│ │ └── internal/ # Internal packages
│ └── runtime/ # Deno runtime
├── docs/ # Documentation
├── examples/ # Example user code
├── scripts/ # Testing and utility scripts
└── docker-compose.yml # Production configuration
# Unit tests
cd services/api && go test ./...
# With coverage
cd services/api && go test -cover ./...
# Verbose output
cd services/api && go test -v ./internal/handlers/...# Full flow test
./scripts/test-full-flow.sh
# Security tests (requires gVisor)
./scripts/test-all-security.sh- Write unit tests for new handlers and functions
- Use the mock executor for handler tests
- Test both success and error cases
Security is critical for this project. If you discover a security vulnerability:
- Do NOT open a public issue
- Email the maintainers directly with details
- Allow time for a fix before public disclosure
When contributing:
- Never commit secrets, credentials, or API keys
- Be cautious with user input handling
- Consider sandbox escape vectors in execution code
- Review gVisor and Docker security implications
- Update README.md for user-facing changes
- Update relevant docs/ files for detailed documentation
- Add inline comments for complex logic
- Include examples for new features
- Open a discussion for general questions
- Check existing issues and discussions first
- Be patient and respectful in all interactions
By contributing, you agree that your contributions will be licensed under the MIT License.