Contributing

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.microsoft.com.

When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repositories using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.

Release Process

This project uses Release Please for automated version management and changelog generation.

How It Works

Conventional Commits: When merging PRs to main, use Conventional Commits format in PR titles or commit messages
Automated Release PR: Release Please will automatically create/update a release PR that:
- Bumps version based on commit types
- Updates CHANGELOG.md
- Updates version.go
Review and Merge: When ready to release, merge the Release Please PR
GitHub Release: A GitHub release with tag will be automatically created

Conventional Commit Prefixes

Prefix	Version Bump	Example
`feat:`	Minor (X.Y.0)	`feat: add connection pooling support`
`fix:`	Patch (X.Y.Z)	`fix: resolve timeout issue`
`feat!:` or `BREAKING CHANGE:`	Major (X.0.0)	`feat!: change API signature`
`docs:`, `chore:`, `ci:`, `deps:`	No bump	Maintenance changes

Example PR Titles

✅ feat: add support for SQL Server 2025
✅ fix: correct datetime handling near midnight
✅ feat!: remove deprecated connection parameters
✅ chore: update dependencies
❌ Update README (should be docs: update README)
❌ Bug fix (should be fix: <description>)

Code Coverage Requirements

This project enforces a strict 80% minimum code coverage requirement to maintain code quality and ensure inclusion in the awesome-go directory.

Requirements

Project coverage: Must stay at or above 80%
Patch coverage: New code in PRs must be at least 80% covered

Checking Coverage Locally

# Run tests with coverage
go test -coverprofile=coverage.out ./...

# View total coverage
go tool cover -func=coverage.out | tail -1

# Generate HTML coverage report
go tool cover -html=coverage.out -o coverage.html

Tips for Maintaining Coverage

Write unit tests for new functions and methods
Test error paths, not just happy paths
Use table-driven tests for comprehensive coverage
Check coverage before submitting PRs

3.1 KiB Raw Blame History