/
advanceddev
/
license-server
Обзор
Документация
Войти
/
advanceddev
/
license-server
Код
Запросы
0
Задачи
Вики
Пакеты
0
Релизы
2
CI/CD
Аналитика
Безопасность
master
CONTRIBUTING
120 строк
4 KB
advanceddev
Create: CONTRIBUTING
09 авг 2026, 20:14
Верифицирован
09 авг 2026, 20:14
c02a851
Код
Авторство
О чём код?
Contributing to CC-WL License Server Thank you for your interest in contributing to CC-WL License Server. This document provides guidelines and information for contributors. How to Contribute Reporting Bugs Before creating a bug report, please check existing issues to avoid duplicates. When filing a bug report, include: - A clear and descriptive title - Steps to reproduce the issue - Expected behavior - Actual behavior - Go version, Docker version, and OS - Relevant log output (structured JSON logs from slog) - Minimal reproduction case if possible Suggesting Features Feature suggestions are welcome. Please open an issue with: - Clear description of the proposed feature - Use case and motivation - Proposed API or interface changes (if applicable) - Any potential breaking changes Please note that this project follows a minimal scope philosophy. Features should serve a clear need for license management in white-label applications. General-purpose features may be declined. Submitting Pull Requests 1. Fork the repository 2. Create a feature branch from main: git checkout -b feature/your-feature-name 3. Make your changes following the coding standards below 4. Write or update tests for new functionality 5. Ensure all tests pass: make test 6. Update documentation if applicable 7. Commit with a clear message following conventional commits format 8. Push to your fork and submit a pull request Pull Request Requirements - All tests must pass (make test) - No linting errors (golangci-lint run ./...) - New code must have appropriate test coverage - Breaking changes must be documented - Keep PRs focused on a single concern Coding Standards Go Code - Follow standard Go conventions and idioms - Run gofmt and goimports before committing - Use structured logging via slog, never fmt.Print or log.Printf - Handle errors explicitly, do not ignore returned errors - Prefer table-driven tests - Use context.Context as the first parameter for functions that perform I/O - Avoid global state; use dependency injection through constructors Project Structure - Domain types and interfaces go in internal/domain - HTTP handlers go in internal/handler - Database and cache implementations go in internal/repository - Middleware goes in internal/middleware - Configuration goes in internal/config - Validation logic goes in internal/validate - SQL migrations go in migrations directory with sequential numbering Database Changes - All schema changes must be done via migrations - Migration files must be numbered sequentially: 001_, 002_, etc. - Migrations must be idempotent where possible - Never modify existing migration files after they have been applied - Include both up and rollback logic when feasible Testing - Unit tests for validation logic and domain rules - Integration tests for handlers using httptest and chi router - Use miniredis for Redis tests, mock repositories for database tests - Tests must pass with race detector enabled (-race flag) - Do not depend on external services in tests Commit Messages Follow conventional commits format: - feat: new feature - fix: bug fix - docs: documentation changes - test: adding or updating tests - refactor: code refactoring without behavior change - chore: maintenance tasks, dependency updates - migrate: database migration changes Examples: - feat: add per-key rate limiting for license validation - fix: prevent nil pointer dereference in audit writer - docs: update README with integration example - test: add coverage for expired license validation Security - Do not commit secrets, API keys, or credentials - Do not disable security features without explicit justification - Report security vulnerabilities privately via Telegram @frntbck, not through public issues - See SECURITY.md for full security policy Communication - Be respectful and constructive in all interactions - See CODE_OF_CONDUCT.md for community standards - For questions, reach out via Telegram @frntbck License By contributing, you agree that your contributions will be licensed under the MIT License.