Contributing

Contributions to SKM are highly encouraged! Whether you are fixing a bug, adding a new cryptographic key type, improving the test coverage, or fixing a typo in this documentation, this guide will help you get your code merged.

Development Environment Setup

  1. Prerequisites: Ensure you have a recent version of Go installed on your system. While the go.mod specifies Go 1.17, the CI pipeline utilizes newer versions (e.g., 1.23) for releasing.

  2. Clone the repository: 

    git clone https://github.com/TimothyYe/skm.git
cd skm

  3. Download Dependencies: SKM uses Go modules. Sync the dependencies to your local cache: 

    go mod tidy

Building and Running Locally

SKM includes a Makefile in the cmd/skm directory to streamline local development.

cd cmd/skm

# Compile the binary to test local changes
make build

# Run your local binary
./skm --help

If you want to install your locally modified version globally on your machine (putting it in your $GOPATH/bin): 

make install

Running the Test Suite

SKM has a robust testing suite designed to ensure key operations are safe. 

# Run all unit tests from the root of the project
go test -v ./...

Understanding Test Mocking

Tests under internal/actions/ do not touch your real ~/.ssh or ~/.skm directories. Instead, the models.Environment struct is utilized to inject randomized temporary directories (e.g., /tmp/skm-testsuite-12345).

If you are writing a new command in internal/actions/, you must use setupTestEnvironment(t) to mock these paths in your tests.

End-to-End (E2E) Tests

Some E2E tests inside cmd/skm/cli_test.go actually invoke the compiled binary. These tests are skipped by default. To trigger them, you must explicitly set an environment variable: 

GOTEST_RUN_E2E=true go test ./cmd/skm/...

Code Standards

Before submitting code, please ensure it adheres to standard Go practices:

  • Run go fmt ./... to ensure consistent formatting.
  • Ensure variables are descriptively named.
  • Keep functions small and focused.
  • If you add a new CLI flag, ensure you add it to the bash completion script (completions/skm.bash) as well.

Pull Request Lifecycle

  1. Fork the Repository: Click the "Fork" button on the GitHub UI.
  2. Branch: Create a descriptively named branch for your feature or fix (git checkout -b feature/support-ecdsa-keys).
  3. Commit: Write clear, concise commit messages.
  4. Push: Push your branch to your fork.
  5. Create PR: Open a Pull Request against the master branch of the upstream repository.

CI/CD Automation

When you open a PR, GitHub Actions will automatically run the go.yml workflow. This workflow checks out your code and runs go test ./... across Ubuntu environments. Your PR cannot be merged if these tests fail.

Releases are automated via the release.yml workflow, which leverages GoReleaser. If you modify how binaries are built or packaged, ensure you audit the .goreleaser.yaml configuration file.