iSharkFly-Docs
/
packer-cn
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Merge pull request #5800 from jessestuart/jesse/cleanup_contributing_docs 

[docs] Fix typos + cleanup CONTRIBUTING.md docs.
This commit is contained in:
Matthew Hooker 2018-01-23 14:34:12 -08:00 committed by GitHub
parent 83bfeb200d a83a22200a
commit 61c17c1d2a
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 100 additions and 71 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

159
CONTRIBUTING.md
View File

@ -1,46 +1,46 @@
# Contributing to Packer # Contributing to Packer
**First:** if you're unsure or afraid of _anything_, just ask **First:** if you're unsure or afraid of _anything_, just ask or submit the
or submit the issue or pull request anyways. You won't be yelled at for issue or pull request anyways. You won't be yelled at for giving your best
giving your best effort. The worst that can happen is that you'll be effort. The worst that can happen is that you'll be politely asked to change
politely asked to change something. We appreciate any sort of contributions, something. We appreciate any sort of contributions, and don't want a wall of
and don't want a wall of rules to get in the way of that. rules to get in the way of that.
However, for those individuals who want a bit more guidance on the However, for those individuals who want a bit more guidance on the best way to
best way to contribute to the project, read on. This document will cover contribute to the project, read on. This document will cover what we're looking
what we're looking for. By addressing all the points we're looking for, for. By addressing all the points we're looking for, it raises the chances we
it raises the chances we can quickly merge or address your contributions. can quickly merge or address your contributions.
## Issues ## Issues
### Reporting an Issue ### Reporting an Issue
* Make sure you test against the latest released version. It is possible * Make sure you test against the latest released version. It is possible we
we already fixed the bug you're experiencing. already fixed the bug you're experiencing.
* Run the command with debug ouput with the environment variable * Run the command with debug output with the environment variable `PACKER_LOG`.
`PACKER_LOG`. For example: `PACKER_LOG=1 packer build template.json`. Take For example: `PACKER_LOG=1 packer build template.json`. Take the _entire_
the *entire* output and create a [gist](https://gist.github.com) for linking output and create a [gist](https://gist.github.com) for linking to in your
to in your issue. Packer should strip sensitive keys from the output, issue. Packer should strip sensitive keys from the output, but take a look
but take a look through just in case. through just in case.
* Provide a reproducible test case. If a contributor can't reproduce an * Provide a reproducible test case. If a contributor can't reproduce an issue,
issue, then it dramatically lowers the chances it'll get fixed. And in then it dramatically lowers the chances it'll get fixed. And in some cases,
some cases, the issue will eventually be closed. the issue will eventually be closed.
* Respond promptly to any questions made by the Packer team to your issue. * Respond promptly to any questions made by the Packer team to your issue. Stale
Stale issues will be closed. issues will be closed.
### Issue Lifecycle ### Issue Lifecycle
1. The issue is reported. 1. The issue is reported.
2. The issue is verified and categorized by a Packer collaborator. 2. The issue is verified and categorized by a Packer collaborator.
Categorization is done via tags. For example, bugs are marked as "bugs" Categorization is done via tags. For example, bugs are marked as "bugs" and
and easy fixes are marked as "easy". easy fixes are marked as "easy".
3. Unless it is critical, the issue is left for a period of time (sometimes 3. Unless it is critical, the issue is left for a period of time (sometimes many
many weeks), giving outside contributors a chance to address the issue. weeks), giving outside contributors a chance to address the issue.
4. The issue is addressed in a pull request or commit. The issue will be 4. 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 referenced in the commit message so that the code that fixes it is clearly
@ -50,86 +50,108 @@ it raises the chances we can quickly merge or address your contributions.
## Setting up Go to work on Packer ## Setting up Go to work on Packer
If you have never worked with Go before, you will have to complete the If you have never worked with Go before, you will have to complete the following
following steps in order to be able to compile and test Packer. These instructions target POSIX-like environments (Mac OS X, Linux, Cygwin, etc.) so you may need to adjust them for Windows or other shells. steps in order to be able to compile and test Packer. These instructions target
POSIX-like environments (Mac OS X, Linux, Cygwin, etc.) so you may need to
adjust them for Windows or other shells.
1. [Download](https://golang.org/dl) and install Go. The instructions below 1. [Download](https://golang.org/dl) and install Go. The instructions below are
are for go 1.7. Earlier versions of Go are no longer supported. for go 1.7. Earlier versions of Go are no longer supported.
2. Set and export the `GOPATH` environment variable and update your `PATH`. For 2. Set and export the `GOPATH` environment variable and update your `PATH`. For
example, you can add to your `.bash_profile`. example, you can add the following to your `.bash_profile` (or comparable
shell startup scripts):
``` ```
export GOPATH=$HOME/go export GOPATH=$HOME/go
export PATH=$PATH:$GOPATH/bin export PATH=$PATH:$GOPATH/bin
``` ```
3. Download the Packer source (and its dependencies) by running `go get 3. Download the Packer source (and its dependencies) by running
github.com/hashicorp/packer`. This will download the Packer source to `go get github.com/hashicorp/packer`. This will download the Packer source to
`$GOPATH/src/github.com/hashicorp/packer`. `$GOPATH/src/github.com/hashicorp/packer`.
4. When working on packer `cd $GOPATH/src/github.com/hashicorp/packer` so you 4. When working on Packer, first `cd` into `$GOPATH/src/github.com/hashicorp/packer`
can run `make` and easily access other files. Run `make help` to get so you can run `make` and easily access other files. Run `make help` to get
information about make targets. information about make targets.
5. Make your changes to the Packer source. You can run `make` in 5. Make your changes to the Packer source. You can run `make` in
`$GOPATH/src/github.com/hashicorp/packer` to run tests and build the packer `$GOPATH/src/github.com/hashicorp/packer` to run tests and build the Packer
binary. Any compilation errors will be shown when the binaries are binary. Any compilation errors will be shown when the binaries are
rebuilding. If you don't have `make` you can simply run `go build -o bin/packer .` from the project root. rebuilding. If you don't have `make` you can simply run
`go build -o bin/packer .` from the project root.
6. After running building packer successfully, use 6. After running building Packer successfully, use
`$GOPATH/src/github.com/hashicorp/packer/bin/packer` to build a machine and `$GOPATH/src/github.com/hashicorp/packer/bin/packer` to build a machine and
verify your changes work. For instance: `$GOPATH/src/github.com/hashicorp/packer/bin/packer build template.json`. verify your changes work. For instance:
`$GOPATH/src/github.com/hashicorp/packer/bin/packer build template.json`.
7. If everything works well and the tests pass, run `go fmt` on your code 7. If everything works well and the tests pass, run `go fmt` on your code before
before submitting a pull-request. submitting a pull-request.
### Opening an Pull Request ### Opening an Pull Request
When you are ready to open a pull-request, you will need to [fork packer](https://github.com/hashicorp/packer#fork-destination-box), push your changes to your fork, and then open a pull-request. When you are ready to open a pull-request, you will need to
[fork Packer](https://github.com/hashicorp/packer#fork-destination-box), push
your changes to your fork, and then open a pull-request.
For example, my github username is `cbednarski` so I would do the following: For example, my github username is `cbednarski`, so I would do the following:
git checkout -b f-my-feature ```
// develop a patch $ git checkout -b f-my-feature
git push https://github.com/cbednarski/packer f-my-feature # Develop a patch.
$ git push https://github.com/cbednarski/Packer f-my-feature
```
From there, open your fork in your browser to open a new pull-request. From there, open your fork in your browser to open a new pull-request.
**Note** Go infers package names from their filepaths. This means `go build` will break if you `git clone` your fork instead of using `go get` on the main packer project. **Note:** Go infers package names from their file paths. This means `go build`
will break if you `git clone` your fork instead of using `go get` on the main
Packer project.
### Tips for Working on Packer ### Tips for Working on Packer
#### Working on forks #### Working on forks
The easiest way to work on a fork is to set it as a remote of the packer project. After following the steps in "Setting up Go to work on Packer": The easiest way to work on a fork is to set it as a remote of the Packer
project. After following the steps in "Setting up Go to work on Packer":
1. Navigate to $GOPATH/src/github.com/hashicorp/packer 1. Navigate to `$GOPATH/src/github.com/hashicorp/packer`
2. Add the remote `git remote add <name of remote> <github url of fork>`. For example `git remote add mwhooker https://github.com/mwhooker/packer.git`. 2. Add the remote by running
`git remote add <name of remote> <github url of fork>`. For example:
`git remote add mwhooker https://github.com/mwhooker/packer.git`.
3. Checkout a feature branch: `git checkout -b new-feature` 3. Checkout a feature branch: `git checkout -b new-feature`
4. Make changes 4. Make changes
5. (Optional) Push your changes to the fork: `git push -u <name of remote> new-feature` 5. (Optional) Push your changes to the fork:
`git push -u <name of remote> new-feature`
This way you can push to your fork to create a PR, but the code on disk still lives in the spot where the go cli tools are expecting to find it. This way you can push to your fork to create a PR, but the code on disk still
lives in the spot where the go cli tools are expecting to find it.
#### Govendor #### Govendor
If you are submitting a change that requires new or updated dependencies, please include them in `vendor/vendor.json` and in the `vendor/` folder. This helps everything get tested properly in CI. If you are submitting a change that requires new or updated dependencies, please
include them in `vendor/vendor.json` and in the `vendor/` folder. This helps
everything get tested properly in CI.
Note that you will need to use [govendor](https://github.com/kardianos/govendor) to do this. This step is recommended but not required; if you don't use govendor please indicate in your PR which dependencies have changed and to what versions. Note that you will need to use [govendor](https://github.com/kardianos/govendor)
to do this. This step is recommended but not required; if you don't use govendor
please indicate in your PR which dependencies have changed and to what versions.
Use `govendor fetch <project>` to add dependencies to the project. See Use `govendor fetch <project>` to add dependencies to the project. See
[govendor quick [govendor quick start](https://github.com/kardianos/govendor#quick-start-also-see-the-faq)
start](https://github.com/kardianos/govendor#quick-start-also-see-the-faq) for for examples.
examples.
Please only apply the minimal vendor changes to get your PR to work. Packer does not attempt to track the latest version for each dependency. Please only apply the minimal vendor changes to get your PR to work. Packer does
not attempt to track the latest version for each dependency.
#### Running Unit Tests #### Running Unit Tests
You can run tests for individual packages using commands like this: You can run tests for individual packages using commands like this:
```
$ make test TEST=./builder/amazon/... $ make test TEST=./builder/amazon/...
```
#### Running Acceptance Tests #### Running Acceptance Tests
@ -137,26 +159,33 @@ Packer has [acceptance tests](https://en.wikipedia.org/wiki/Acceptance_testing)
for various builders. These typically require an API key (AWS, GCE), or for various builders. These typically require an API key (AWS, GCE), or
additional software to be installed on your computer (VirtualBox, VMware). additional software to be installed on your computer (VirtualBox, VMware).
If you're working on a new builder or builder feature and want verify it is functioning (and also hasn't broken anything else), we recommend running the If you're working on a new builder or builder feature and want verify it is
functioning (and also hasn't broken anything else), we recommend running the
acceptance tests. acceptance tests.
**Warning:** The acceptance tests create/destroy/modify *real resources*, which **Warning:** The acceptance tests create/destroy/modify _real resources_, which
may incur costs for real money. In the presence of a bug, it is possible that resources may be left behind, which can cost money even though you were not using them. We recommend running tests in an account used only for that purpose so it is easy to see if there are any dangling resources, and so production resources are not accidentally destroyed or overwritten during testing. may incur costs for real money. In the presence of a bug, it is possible that
resources may be left behind, which can cost money even though you were not
using them. We recommend running tests in an account used only for that purpose
so it is easy to see if there are any dangling resources, and so production
resources are not accidentally destroyed or overwritten during testing.
To run the acceptance tests, invoke `make testacc`: To run the acceptance tests, invoke `make testacc`:
```
$ make testacc TEST=./builder/amazon/ebs $ make testacc TEST=./builder/amazon/ebs
... $ ...
```
The `TEST` variable lets you narrow the scope of the acceptance tests to a The `TEST` variable lets you narrow the scope of the acceptance tests to a
specific package / folder. The `TESTARGS` variable is recommended to filter specific package / folder. The `TESTARGS` variable is recommended to filter down
down to a specific resource to test, since testing all of them at once can to a specific resource to test, since testing all of them at once can sometimes
sometimes take a very long time. take a very long time.
To run only a specific test, use the `-run` argument: To run only a specific test, use the `-run` argument:
``` ```
make testacc TEST=./builder/amazon/ebs TESTARGS="-run TestBuilderAcc_forceDeleteSnapshot" $ make testacc TEST=./builder/amazon/ebs TESTARGS="-run TestBuilderAcc_forceDeleteSnapshot"
``` ```
Acceptance tests typically require other environment variables to be set for Acceptance tests typically require other environment variables to be set for