git-secret/CONTRIBUTING.md

Contributing

Your contributions are always welcome!

Process

Environment

Before starting make sure you have:

• git
• bash
• bundler
• docker
• gawk
• gnupg (or gnupg2)
• ruby
• sha256sum
• shellcheck
• test-kitchen

Only required if dealing with manuals, gh-pages or releases:

• ruby, ruby-dev

Environment MacOS

• install Docker for Mac
• install Chef Developer Kit
• install Homebrew
• install ruby2.4 and kitchen dependencies with brew install rbenv ruby-build rbenv-vars; rbenv install 2.4.4; rbenv rehash; rbenv global 2.4.4 ;gem install bundler kitchen-ansible serverspec kitchen-docker kitchen-verifier-serverspec

Getting started

1. Create your own or pick an opened issue from the tracker. Take a look at the help-wanted tag
2. Fork and clone your repository: git clone https://github.com/${YOUR_NAME}/git-secret.git
3. Make sure that everything works on the current platform by running make test
4. Run local CI tests to verify functionality on supported platforms bundle exec kitchen verify --test-base-path="$PWD/.ci/integration".

Development Process

1. Firstly, you will need to setup development hooks with make install-hooks
2. Make changes to the files that need to be changed
3. When making changes to any files inside src/ you will need to rebuild the binary git-secret with make clean && make build command
4. Run shellcheck against all your changes with make lint
5. Now, add all your files to the commit with git add --all and commit changes with git commit, make sure you write a good message, which will explain your work
6. When running git commit the tests will run automatically, your commit will be canceled if they fail
7. Push to your repository, make a pull-request against master branch. Please, make sure you have one commit per pull-request, it will be merge into one anyways

Branches

We have two long-live branches: master and gh-pages for static web site.

It basically looks like this:

your-branch -> master

• master branch is protected. So only fully tested code goes there. It is also used to create a new git tag and a github release

Continuous integration

Local CI is done with the help test-kitchen. test-kitchen handles multiple test-suites on various platforms. bundle exec kitchen list will output the list of test suites to be run against supported platforms.

Cloud CI is done with the help of travis. travis handles multiple environments:

• Docker-based jobs or so-called 'integration tests', these tests create a local release, install it with the package manager and then run unit-tests and system checks
• OSX jobs, which handle basic unit-tests on OSX
• Native travis jobs, which handle basic unit-tests and style checks

Running local ci-tests

1. Install required gems with bundle install.
2. Run ci-tests with bundle exec kitchen verify --test-base-path="$PWD/.ci/integration"

Release process

The release process is defined in the git-hooks and .travis.yml.

When creating a commit inside the master branch (it is usually a documentation and changelog update with the version bump inside src/version.sh) it will trigger two main events.

Firstly, new manuals will be created and added to the current commit with make build-man on pre-commit hook.

Secondly, after the commit is successfully created it will also trigger make build-gh-pages target on post-commit hook, which will push new manuals to the git-secret site. And the new git tag will be automatically created if the version is changed:

if [[ "$NEWEST_TAG" != "v${SCRIPT_VERSION}" ]]; then
  git tag -a "v${SCRIPT_VERSION}" -m "version $SCRIPT_VERSION"
fi

About GnuPG

Here are some links to gnupg documentation that might be useful for those working with git-secret:

• GnuPG PDF Documentation
• GnuPG doc/DETAILS File

Travis releases

After you commit a tag that matches the pattern '^v.*$' and the tests succeed, Travis should publish new deb and rpm packages to bintray.

If you wish to override a previous release (be careful) you will need to add "override": 1 into matrixParams, see deb-deploy.sh and rpm-deploy.sh

Manual releases

Releases to brew are made manually.

Dockerhub releases

Dockerhub contains Docker images with different OS'es used for testing. It is updated via a github webhook on commit into master.

Downstream Packages

There are several distibutions and packaging systems that may already have git-secret packaged for your distribution (although sometimes their versions are not the most current, and we recommend all users upgrade to 0.2.5 or above).

Notes to Downstream Packagers (Those who make packages for specific OSes/distributions)

First of all, thank you for packaging git-secret for your platform! We appreciate it.

We also would like to welcome you to collaborate or discuss any issues, ideas or thoughts you have about git-secret by submitting issue report (which can also be feature requests) or pull requests via the git repo at git-secret on github

Please let us know if there are any changes you'd like to see to the source, packaging, testing, documentation, or other aspect of git-secret. We look forward to hearing from you.

Financial contributions

We also welcome financial contributions in full transparency on our open collective. Anyone can file an expense. If the expense makes sense for the development of the community, it will be "merged" in the ledger of our open collective by the core contributors and the person who filed the expense will be reimbursed.

Credits

Contributors

Thank you to all the people who have already contributed to git-secret via commits to our git repository!

Backers

Thank you to all our backers! [Become a backer]

Sponsors

Thank you to all our sponsors! (please ask your company to also support this open source project by becoming a sponsor)