First: if you're unsure or afraid of anything, just ask or submit the issue or pull request anyways. You won't be yelled at for giving your best effort. The worst that can happen is that you'll be politely asked to change something. We appreciate any sort of contributions, and don't want a wall of rules to get in the way of that.
However, for those people who want a bit more guidance on the best way to contribute to the project, read on. This document will cover what we're looking for. By addressing all the points we're looking for, it raises the chances we can quickly merge or address your contributions.
-
Make sure you test against the latest released version. It is possible we already fixed the bug you're experiencing.
-
If you experienced a panic, please create a gist of the entire generated crash log for us to look at. Double check no sensitive items were in the log.
-
Respond as promptly as possible to any questions made by the doctl team to your issue. Stale issues will be closed.
-
The issue is reported.
-
The issue is verified and categorized by a doctl collaborator. Categorization is done via labels. For example, bugs are marked as "bugs".
-
Unless it is critical, the issue is left for a period of time (sometimes many weeks), giving outside contributors a chance to address the issue.
-
The issue is addressed in a pull request or commit. The issue will be referenced in the commit message so that the code that fixes it is clearly linked.
-
The issue is closed. Sometimes, valid issues will be closed to keep the issue tracker clean. The issue is still indexed and available for future viewers, or can be re-opened if necessary.
If you have never worked with Go before, you will have to complete the following steps in order to be able to compile and test doctl.
-
Install Go. Make sure the Go version is at least Go 1.6. On Mac OS X, you can
brew install go
to install the latest stable version. -
Set and export the
GOPATH
environment variable and update yourPATH
. For example, you can add to your.bash_profile
.export GOPATH=$HOME/Documents/golang export PATH=$PATH:$GOPATH/bin
-
Make your changes to the doctl source, being sure to run the basic tests.
-
If everything works well and the tests pass, run
go fmt
on your code before submitting a pull request.
When you upgrade godo
you have to re-generate the mocks using mockery,
so first install mockery in your GOPATH
then run the script/regenmocks.sh
script to produce them.
To release doctl
, you need to install:
And make them available in your PATH
. You can use go get -u
for both of them and add your
$GOPATH/bin
to your PATH
so your scripts will find them.
You will also need a valid GITHUB_TOKEN
environment variable with access to the digitalocean/doctl
repo. You can generate a token here, it needs the public_repo
access.
-
Make sure the CHANGELOG contains all changes for the version you're going to release.
Update the version in:
README.md
doit.go
Dockerfile
snap/snapcraft.yml
-
Generate a PR, get it reviewed, and merge
-
To build
doctl
for all its platforms, runscripts/stage.sh major minor patch
(e.g.scripts/stage.sh 1 5 0
). This will place all files and their checksums inbuilds/major.minor.patch/release
. -
Mark the release on GitHub with
scripts/release.sh v<version>
(e.g.scripts/release.sh v1.5.0
, note thev
), -
Upload using
scripts/upload.sh <version>
. -
Go to releases and update the release description to contain all changelog entries for this specific release. Uncheck the pre-release checkbox.
Using the url and sha from the github release, update the
homebrew formula.
You can use brew bump-formula-pr doctl
, or
- fork
homebrew-core
- create a branch named
doctl-<version>
- update the url and the sha256 using the values for the archive in the github release
- commit your changes
- submit a PR to homebrew