Contributing to xenvsync
Thank you for considering a contribution. This guide covers everything from local setup to PR expectations, code style, commit conventions, and security disclosure.
Development Setup
Prerequisites: Go 1.25+, Git. Optionally install golangci-lint and govulncheck for richer local checks.
Making Changes
main branch. Keep commits focused and atomic — one logical change per commit.Pull Request Checklist
Code Style
gofmtAll code must be formatted with gofmt. CI enforces this.
go vetNo vet warnings allowed. Run go vet ./... before pushing.
golangci-lintOptionally install golangci-lint for broader static analysis.
govulncheckScan for known vulnerabilities with govulncheck ./...
Small functionsKeep functions focused and well-named. Avoid long multi-purpose functions.
CommentsOnly add comments where the logic is not self-evident. Avoid redundant comments.
Commit Message Conventions
Use the imperative mood in the first line. Keep it under 72 characters. Reference issues when applicable.
Testing Requirements
xenvsync uses table-driven tests. New functionality must include tests covering normal paths, malformed input, and negative/error paths.
Command tests in cmd/*_test.go use temporary directories and invoke Cobra directly. Do not depend on global state.
High-Risk Areas
These areas require extra care and thorough testing before any changes:
run command
Child process exit code propagation and signal forwarding (SIGINT/SIGTERM) must work correctly on Linux, macOS, and Windows.
rotate command
Vault is written before key to ensure rollback safety. Do not change this ordering.
Fallback merge precedence
.env.shared < .env.<name> < .env.local. Ensure layer order is preserved.
V1/V2 vault detection
decryptVault() auto-detects format. Changes must not break backward compatibility with V1 vaults.
Key permissions
Key files must be written with mode 0600. Identity files must also be 0600.
Memory zeroing
Key material must be zeroed after use via crypto.ZeroBytes.
Documentation Updates
When making user-visible behavior changes, update the following files alongside code:
- –README.md — feature overview and command reference
- –CONTRIBUTING.md — if contributing workflow changes
- –docs/INSTALL.md — if installation steps change
- –docs/ARCHITECTURE.md — if design boundaries shift
- –CHANGELOG.md — add entry under the next version
Reporting Issues
Use GitHub Issues to report bugs or request features.
Include:
- –Steps to reproduce the issue
- –Expected vs. actual behavior
- –Your OS and Go version (xenvsync version output)
- –Relevant error output