Skip to content

Latest commit

 

History

History
213 lines (163 loc) · 7.3 KB

CONTRIBUTING.md

File metadata and controls

213 lines (163 loc) · 7.3 KB
Raw

License: MIT v3


go-printers

A Golang module built on top of the spf13/pflag library to assist with abstracting output formatting.
README · CHANGELOG . CONTRIBUTING
Report Bug · Request Feature

Table of contents

Contributions make the open source community an great place to learn, inspire, and create.

Please review this contribution guide to streamline your experience.

Review existing issues

Please review existing issues before reporting bug reports or requesting new features.

A quick discussion to coordinate a proposed change before you start can save hours of rework.

Setup for local development

Install prerequisites

  • Make - often comes bundled with C compiler tools

  • Golang 1.18

    • with a working go installation: 
      go install golang.org/dl/go1.18@latest
go1.18 download
    • open a terminal with go1.18 as the linked go binary

  • ruby 3.0.2 [optional]

    • this project offers ruby and guard to provide real-time validation of grammar and spelling in key markdown files
    • use a ruby version manager like rbenv or asdf; or
    • install directly from ruby-lang.org

Get the code

  1. Fork the repository on Github

  2. Clone your fork

    git clone https://github.com/your-github-name/go-printers.git

Visit the doctor

This repository includes a doctor.sh script which validates development dependencies.

  1. Verify dependencies 
    ./.tools/doctor.sh

This script attempts to fix basic issues, for example by running go get or bundle install.

If doctor.sh reports an issue that it can't resolve you may need to help it by taking action.

Please log any issues with the doctor script by reporting a bug.

Run locally

  1. Build and run the tests 
    make test

Useful Make targets

This repository includes a Makefile for help running common tasks.

Run make with no arguments to list the available targets:

$ make

 go-printers 0.0.0 - available targets:

changelog                      Generate/update CHANGELOG.md
cit                            clean build and test-unit
clean                          clean build output
doctor                         run doctor.sh to sort out development dependencies
gen                            invoke go generate
guard                          run ruby-guard
preview-release-notes          preview release notes (generates RELEASE_NOTES.md)
preview-release                preview release (using goreleaser --snapshot)
test-unit                      run unit tests
test                           run unit tests
vale                           run linting rules against markdown files
version                        show current version
----------                     ------------------
release-major                  release major version
release-minor                  release minor version
release-patch                  release patch version

Development workflow

This project follows a standard open source fork/pull-request workflow:

  1. First, fork the repository on Github

  2. Create your Feature Branch

    git checkout -b 123-amazing-feature

  3. Commit your Changes

    git commit -m 'Add some AmazingFeature'

  4. Make sure the code builds and all tests pass

    make cit

  5. Push to the Branch

    git push origin 123-amazing-feature

  6. Open a Pull Request

    https://github.com/davidalpert/go-printers/compare/123-amazing-feature

Branch names

When working on a pull request to address or resolve a Github issue, prefix the branch name with the Github issue number.

In the preceding example, after picking up an issue with an id of 123, create a branch which starts with GH-123 or just 123- and a hyphenated description:

git checkout -b 123-amazing-feature

Commit message guidelines

This project uses conventional commits to generate CHANGELOG.

Format of a conventional commit:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

List of supported commit type tags include:

  - "build"    # Changes that affect the build system or external dependencies
  - "ci"       # Changes to our CI configuration files and scripts 
  - "docs"     # Documentation only changes
  - "feat"     # A new feature
  - "fix"      # A bug fix
  - "perf"     # A code change that improves performance
  - "refactor" # A code change that neither fixes a bug nor adds a feature
  - "test"     # Adding missing tests or correcting existing tests

Prefix your commits with one of these type tags to automatically include the commit description in the CHANGELOG for the next release.