mirror of
https://github.com/octoleo/restic.git
synced 2024-11-04 20:37:49 +00:00
182 lines
6.8 KiB
Markdown
182 lines
6.8 KiB
Markdown
This document describes the way you can contribute to the restic project.
|
|
|
|
Ways to Help Out
|
|
================
|
|
|
|
Thank you for your contribution!
|
|
|
|
There are several ways you can help us out. First of all code contributions and
|
|
bug fixes are most welcome. However even "minor" details as fixing spelling
|
|
errors, improving documentation or pointing out usability issues are a great
|
|
help also.
|
|
|
|
|
|
The restic project uses the GitHub infrastructure (see the
|
|
[project page](https://github.com/restic/restic)) for all related discussions
|
|
as well as the `#restic` channel on `irc.freenode.net`.
|
|
|
|
If you want to find an area that currently needs improving have a look at the
|
|
open issues listed at the
|
|
[issues page](https://github.com/restic/restic/issues). This is also the place
|
|
for discussing enhancement to the restic tools.
|
|
|
|
If you are unsure what to do, please have a look at the issues, especially
|
|
those tagged
|
|
[minor complexity](https://github.com/restic/restic/labels/minor%20complexity).
|
|
|
|
|
|
Reporting Bugs
|
|
==============
|
|
|
|
You've found a bug? Thanks for letting us know so we can fix it! It is a good
|
|
idea to describe in detail how to reproduce the bug (when you know how), what
|
|
environment was used and so on. Please tell us at least the following things:
|
|
|
|
* What's the version of restic you used? Please include the output of
|
|
`restic version` in your bug report.
|
|
* What commands did you execute to get to where the bug occurred?
|
|
* What did you expect?
|
|
* What happened instead?
|
|
* Are you aware of a way to reproduce the bug?
|
|
|
|
Remember, the easier it is for us to reproduce the bug, the earlier it will be
|
|
corrected!
|
|
|
|
In addition, you can compile restic with debug support by running
|
|
`go run build.go -tags debug` and instructing it to create a debug log by
|
|
setting the environment variable `DEBUG_LOG` to a file, e.g. like this:
|
|
|
|
$ export DEBUG_LOG=/tmp/restic-debug.log
|
|
$ restic backup ~/work
|
|
|
|
Please be aware that the debug log file will contain potentially sensitive
|
|
things like file and directory names, so please either redact it before
|
|
uploading it somewhere or post only the parts that are really relevant.
|
|
|
|
|
|
Development Environment
|
|
=======================
|
|
|
|
For development you need the build tool [`gb`](https://getgb.io), it can be
|
|
installed by running the following command:
|
|
|
|
$ go get github.com/constabulary/...
|
|
|
|
The repository contains two directories with code: `src/` contains the code
|
|
written for restic, whereas `vendor/` contains copies of libraries restic
|
|
depends on. The libraries are managed with the `gb vendor` command.
|
|
|
|
Just clone the repository, `cd` to it and run `gb build` to build the binary:
|
|
|
|
$ git clone https://github.com/restic/restic
|
|
$ cd restic
|
|
$ gb build
|
|
[...]
|
|
$ bin/restic version
|
|
restic compiled manually
|
|
compiled at unknown time with go1.6
|
|
|
|
The following commands can be used to run all the tests:
|
|
|
|
$ gb test
|
|
ok github.com/restic/restic 8.174s
|
|
[...]
|
|
|
|
If you want to run your tests on Linux, OpenBSD or FreeBSD, you can use
|
|
[vagrant](https://www.vagrantup.com/) with the proveded `Vagrantfile` to
|
|
quickly set up VMs and run the tests, e.g.:
|
|
|
|
$ vagrant up freebsd
|
|
[...]
|
|
|
|
$ vagrant ssh freebsd -c 'cd restic/restic; go test -v ./...'
|
|
[...]
|
|
|
|
Providing Patches
|
|
=================
|
|
|
|
You have fixed an annoying bug or have added a new feature? Very cool! Let's
|
|
get it into the project! The workflow we're using is also described on the
|
|
[GitHub Flow](https://guides.github.com/introduction/flow/) website, it boils
|
|
down to the following steps:
|
|
|
|
0. If you want to work on something, please add a comment to the issue on
|
|
GitHub. For a new feature, please add an issue before starting to work on
|
|
it, so that duplicate work is prevented.
|
|
|
|
1. First we would kindly ask you to fork our project on GitHub if you haven't
|
|
done so already.
|
|
|
|
2. Clone the repository locally and create a new branch. If you are working on
|
|
the code itself, please set up the development environment as described in
|
|
the previous section.
|
|
|
|
3. Then commit your changes as fine grained as possible, as smaller patches,
|
|
that handle one and only one issue are easier to discuss and merge.
|
|
|
|
4. Push the new branch with your changes to your fork of the repository.
|
|
|
|
5. Create a pull request by visiting the GitHub website, it will guide you
|
|
through the process.
|
|
|
|
6. You will receive comments on your code and the feature or bug that they
|
|
address. Maybe you need to rework some minor things, in this case push new
|
|
commits to the branch you created for the pull request, they will be
|
|
automatically added to the pull request.
|
|
|
|
7. Once your code looks good and passes all the tests, we'll merge it. Thanks
|
|
a low for your contribution!
|
|
|
|
Please provide the patches for each bug or feature in a separate branch and
|
|
open up a pull request for each.
|
|
|
|
The restic project uses the `gofmt` tool for Go source indentation, so please
|
|
run
|
|
|
|
gofmt -w **/*.go
|
|
|
|
in the project root directory before committing. Installing the script
|
|
`fmt-check` from https://github.com/edsrzf/gofmt-git-hook locally as a
|
|
pre-commit hook checks formatting before committing automatically, just copy
|
|
this script to `.git/hooks/pre-commit`.
|
|
|
|
For each pull request, several different systems run the integration tests on
|
|
Linux, OS X and Windows. We won't merge any code that does not pass all tests
|
|
for all systems, so when a tests fails, try to find out what's wrong and fix
|
|
it. If you need help on this, please leave a comment in the pull request, and
|
|
we'll be glad to assist. Having a PR with failing integration tests is nothing
|
|
to be ashamed of. In contrast, that happens regularly for all of us. That's
|
|
what the tests are there for.
|
|
|
|
Git Commits
|
|
-----------
|
|
|
|
I would be good if you could follow the same general style regarding Git
|
|
commits as the rest of the project, this makes reviewing code, browsing the
|
|
history and triaging bugs much easier.
|
|
|
|
Git commit messages have a very terse summary in the first line of the commit
|
|
message, followed by an empty line, followed by a more verbose description or a
|
|
List of changed things. For examples, please refer to the excellent [How to
|
|
Write a Git Commit Message](http://chris.beams.io/posts/git-commit/).
|
|
|
|
If you change/add multiple different things that aren't related at all, try to
|
|
make several smaller commits. This is much easier to review. Using `git add -p`
|
|
allows staging and committing only some changes.
|
|
|
|
Code Review
|
|
===========
|
|
|
|
The restic project encourages actively reviewing the code, as it will store
|
|
your precious data, so it's common practice to receive comments on provided
|
|
patches.
|
|
|
|
If you are reviewing other contributor's code please consider the following
|
|
when reviewing:
|
|
|
|
* Be nice. Please make the review comment as constructive as possible so all
|
|
participants will learn something from your review.
|
|
|
|
As a contributor you might be asked to rewrite portions of your code to make it
|
|
fit better into the upstream sources.
|