Skip to content

Contributing

Thank you for helping improve babyctl! This guide explains expectations for contributors and maintainers.

Code of conduct

Be excellent to each other. Treat all community members with respect and empathy.

Workflow

  1. Fork the repository or create a feature branch.
  2. Make your changes with clear, focused commits.
  3. Add or update tests when behaviour changes.
  4. Run make check locally to ensure formatting, linting, and tests all pass.
  5. Open a pull request describing the change and referencing any related issues.

Commit messages

babyctl uses Conventional Commits. Examples:

git commit -m "fix: patch panic when provider list is empty"
git commit -m "feat: add diff command"
git commit -m "feat!: redesign apply flow\n\nBREAKING CHANGE: requires explicit provider"

Following this format allows release-please to determine semantic version bumps automatically.

Review checklist

  • [ ] Code is formatted with go fmt.
  • [ ] Tests pass locally (make test).
  • [ ] User-facing changes are documented under docs/.
  • [ ] New commands include helpful examples in Examples blocks.
  • [ ] CLI output changes are covered by tests or manually verified screenshots/logs.

Release workflow

Releases are driven by release-please:

  1. Merge changes into main using Conventional Commits.
  2. release-please opens or updates a release PR when it detects new commits.
  3. Once the release PR is merged, GitHub Actions publishes binaries (linux/darwin/windows for amd64+arm64), SHA256 checksums, and auto-generated changelog entries.

Documentation site

Docs live under docs/ and are rendered with MkDocs Material.

pip install mkdocs-material
mkdocs serve

This spins up a live-reloading dev server at http://127.0.0.1:8000. Submit doc updates alongside code changes whenever possible.

Questions?

Open an issue or start a discussion on GitHub. We're excited to see what you build!