Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
80 lines (60 loc) · 2.54 KB

CONTRIBUTING.md

File metadata and controls

80 lines (60 loc) · 2.54 KB

Contributing to dtasks

Thanks for taking the time to contribute.

Getting started

git clone https://github.com/danielmrdev/dtasks-cli
cd dtasks
go mod tidy
go build ./...
go test ./...

Common make targets:

Command Description
make build Build native binary → dist/dtasks
make install Build and copy to ~/.local/bin/dtasks
make build-all Build all release targets → dist/
make run ARGS="ls" Run without installing
make release TAG=v1.2.3 Tag and push to trigger the release workflow
make help List all available targets

Workflow

  1. Open an issue before starting non-trivial work so we can discuss the approach.
  2. Fork the repository and create a branch from main: 
    git checkout -b fix/short-description
git checkout -b feat/short-description
  3. Make your changes. Keep commits focused and atomic.
  4. Run the checks locally before pushing: 
    go vet ./...
go test ./...
  5. Open a pull request against main. Fill in the PR template.

Code style

  • Standard Go formatting — run gofmt or goimports before committing.
  • Keep functions small and focused. Prefer clarity over cleverness.
  • All new behaviour should have a test in the same package (_test.go next to the file).
  • No CGO. The project must build with CGO_ENABLED=0 on all target platforms.

Project layout

cmd/         CLI commands (cobra). No business logic here.
internal/
  config/    Config file loading and first-run wizard.
  db/        SQLite open + PRAGMAs + migration.
  models/    Plain structs. No methods, no dependencies.
  repo/      Database queries. Pure functions, no global state.
  output/    Table and JSON rendering.

New packages under internal/ are welcome for new features. Avoid adding dependencies to the module root (cmd/) beyond cobra.

Reporting bugs

Use the bug report template. Include your platform, dtasks version (dtasks --version), and the exact command that failed.

Suggesting features

Use the feature request template.

Versioning

This project follows Semantic Versioning. Changes are documented in CHANGELOG.md.

To publish a release:

make release TAG=v1.2.3

This creates a git tag and pushes it, which triggers the GitHub Actions release workflow.