Skip to content

Latest commit

 

History

History
45 lines (33 loc) · 2.86 KB

CONTRIBUTING.md

File metadata and controls

45 lines (33 loc) · 2.86 KB
Raw

Contributing

First of all, thank you for your interest in contributing to this project.

Before creating a pull request, please read and follow this contributing guide. Before participating in this project's activities, please read and follow code of conduct.

Please create an issue before submitting a pull request. If it is a proposal for a new feature or changing existing functionality, initiate a discussion with maintainers first. If it's a fix for know bugs, a discussion is not required.

Developing

  • Install Go.
  • The project uses Makefile. Install make command.
  • Fork this repository.
  • Clone the forked repository.
  • Make changes (see Formatting) and commit to your fork. Commit messages should follow the Conventional Commits style.
  • Add appropriate unit tests (see Testing) for your changes.
  • Update documentation if appropriate.
  • Create a pull request with your changes.
  • Github action will run the necessary checks against your pull request.
  • A maintainer will review the pull request once all checks are
  • A maintainer will merge and create a release (see Releasing).

Testing

All changes must be unit tested and meet the project test coverage threshold (73%) requirement. Run make test to run all tests and generate coverage reports before submitting a pull request.

To write the bats tests for plugin,

  1. Modify the tests
  2. Run docker-compose build plugin_test && docker-compose run --rm plugin_test

Formatting

All code must be formatted with gofmt (with the latest Go version) and pass go vet. The plugin must be linted with buildkite-plugin-linter. Run make quality to run all formatting checks.

Releasing

One of the maintainers will create a release after merging the pull request.

  • Ensure documentation is updated appropriately.
  • Update README.md to the next version number.
  • Update changelog using guidelines from Keep a Changelog.
  • Merge changes to master.
  • Create a new release. The version number must follow the format of v<major>.<minor>.<patch>. Eg. v2.0.1
  • Github actions automatically builds and attachs the binary to the release.