Contributing

All contributions are welcome and appreciated. Feel free to open issues or pull requests for any fixes, changes, or new features, and if you are not sure about anything, open it anyway. Issues and pull requests are a great forum for discussion and a great opportunity to help improve the code as a whole.

Opening Issues

A great way to contribute to the project is to open GitHub issues whenever you encounter any issue, or if you have an idea on how Tusk can improve. Missing or incorrect documentation are issues too, so feel free to open one whenever you feel there is a chance to make Tusk better.

When reporting a bug, make sure to include the expected behavior and steps to reproduce. The more descriptive you can be, the faster the issue can be resolved.

Opening Pull Requests

Always feel free to open a pull request, whether it is a fix or a new addition. For big or breaking changes, you might consider opening an issue first to check interest, but it is absolutely not required to make a contribution.

Tests are run automatically on each PR, and 100% test and lint pass rate is required to get the code merged in, although it is fine to have work-in- progress pull requests open while debugging. Details on how to run the test suite can be found here.

For features which change the spec of the configuration file, documentation should be added in docs/spec.md.

Setting Up a Development Environment

For local development, you will need Go version 1.11+ installed.

Tusk uses go modules for dependency management, so make sure to clone the project outside of the GOPATH. If that doesn't mean anything to you, you're probably fine.

git clone https://github.com/rliebz/tusk.git

If it is not already on your path, you probably also want to have the GOPATH binary directory available for projects installed by go get and go install. To do so, add the following to your .bash_profile or .zshrc:

export PATH="$PATH:$(go env GOPATH)/bin"

To install Tusk:

go install

If you have already installed tusk from another source, make sure you test against the development version installed locally. If you do not get (devel) as the version, you may need to move your Go binary path earlier in your PATH:

$ tusk --version
(devel)

Making Changes

If you have not yet done so, make sure you fork the repository so you can push your changes back to your own fork on GitHub.

When starting work on a new feature, create a new branch based off the main branch. Pull requests should generally target the main branch, and releases will be cut separately.

Running Tests

To run the unit tests:

tusk test

To run the full test suite, along with the linter:

tusk test -a

If the linter fails, execution will stop short and not actually run the unit test suite. If there is a linter error that is a false-positive, or the violation is necessary for your contribution, you can disable a specific linter for that line:

cmd := exec.Command("sh", "-c", command) // nolint: gosec