Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
103 lines (70 loc) · 2.98 KB

CONTRIBUTING.md

File metadata and controls

103 lines (70 loc) · 2.98 KB

Contributing

Below are some helpful directions on getting your environment set up as well as contributing guidelines.

Prerequisites

  • Go 1.21+
  • Python 3.12+
  • uv (Python package manager)
  • Pulumi
  • just (command runner)
  • AWS CLI or Azure CLI (depending on your cloud provider)
  • snyk CLI (optional, for security scanning)

Git Hooks

Pre-commit hooks run automatically when you commit. They will:

  • Format and lint your code
  • Run tests for the files you changed (e.g., Python tests only if you changed Python files)

If a hook fails, the commit is blocked. Fix the issue, stage the fix, and commit again.

# Run hooks manually on all files
pre-commit run --all-files

# Skip all hooks
git commit --no-verify -m "message"

# Skip specific hooks only
SKIP=test-python-pulumi git commit -m "message"
SKIP=test-python-pulumi,test-cmd git commit -m "message"

Commit Message Format

This project uses Conventional Commits for automatic versioning and changelog generation.

Format

<type>(<scope>): <description>

[optional body]

[optional footer(s)]

Types

Type Description Version Bump
feat New feature Minor (0.X.0)
fix Bug fix Patch (0.0.X)
docs Documentation only None
style Code style (formatting, etc.) None
refactor Code change that neither fixes nor adds None
perf Performance improvement Patch
test Adding/updating tests None
chore Maintenance tasks None

Breaking Changes

For breaking changes, add ! after the type or include BREAKING CHANGE: in the footer:

feat!: remove deprecated API endpoint

BREAKING CHANGE: The /v1/legacy endpoint has been removed.

Breaking changes trigger a major version bump (X.0.0).

Examples

feat(cli): add proxy command for cluster access
fix(aws): correct IAM policy for EKS access
docs: update installation instructions
chore: update dependencies

Releases

Releases are automated via GitHub Actions. When commits are pushed to main:

  1. semantic-release analyzes commits
  2. If releasable changes exist, a new version is determined
  3. CHANGELOG.md is updated
  4. A GitHub release is created with the new tag
  5. CLI binaries are built and attached to the release

Setting up snyk

It is helpful to be able to run snyk locally for development (particularly if a PR fails the snyk test).

Our expectation is that snyk would be passing before merging a given PR

  1. Install the snyk CLI. On Mac systems, you can run brew install snyk-cli

  2. Run snyk auth. This authenticates your local CLI with your credentials.

  3. Run snyk test --all-projects --policy-path=.snyk from the root directory to check for vulnerabilities.