github.com/rsyabuta/packer@v1.1.4-0.20180119234903-5ef0c2280f0b/CONTRIBUTING.md (about) 1 # Contributing to Packer 2 3 **First:** if you're unsure or afraid of _anything_, just ask 4 or submit the issue or pull request anyways. You won't be yelled at for 5 giving your best effort. The worst that can happen is that you'll be 6 politely asked to change something. We appreciate any sort of contributions, 7 and don't want a wall of rules to get in the way of that. 8 9 However, for those individuals who want a bit more guidance on the 10 best way to contribute to the project, read on. This document will cover 11 what we're looking for. By addressing all the points we're looking for, 12 it raises the chances we can quickly merge or address your contributions. 13 14 ## Issues 15 16 ### Reporting an Issue 17 18 * Make sure you test against the latest released version. It is possible 19 we already fixed the bug you're experiencing. 20 21 * Run the command with debug ouput with the environment variable 22 `PACKER_LOG`. For example: `PACKER_LOG=1 packer build template.json`. Take 23 the *entire* output and create a [gist](https://gist.github.com) for linking 24 to in your issue. Packer should strip sensitive keys from the output, 25 but take a look through just in case. 26 27 * Provide a reproducible test case. If a contributor can't reproduce an 28 issue, then it dramatically lowers the chances it'll get fixed. And in 29 some cases, the issue will eventually be closed. 30 31 * Respond promptly to any questions made by the Packer team to your issue. 32 Stale issues will be closed. 33 34 ### Issue Lifecycle 35 36 1. The issue is reported. 37 38 2. The issue is verified and categorized by a Packer collaborator. 39 Categorization is done via tags. For example, bugs are marked as "bugs" 40 and easy fixes are marked as "easy". 41 42 3. Unless it is critical, the issue is left for a period of time (sometimes 43 many weeks), giving outside contributors a chance to address the issue. 44 45 4. The issue is addressed in a pull request or commit. The issue will be 46 referenced in the commit message so that the code that fixes it is clearly 47 linked. 48 49 5. The issue is closed. 50 51 ## Setting up Go to work on Packer 52 53 If you have never worked with Go before, you will have to complete the 54 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. 55 56 1. [Download](https://golang.org/dl) and install Go. The instructions below 57 are for go 1.7. Earlier versions of Go are no longer supported. 58 59 2. Set and export the `GOPATH` environment variable and update your `PATH`. For 60 example, you can add to your `.bash_profile`. 61 62 ``` 63 export GOPATH=$HOME/go 64 export PATH=$PATH:$GOPATH/bin 65 ``` 66 67 3. Download the Packer source (and its dependencies) by running `go get 68 github.com/hashicorp/packer`. This will download the Packer source to 69 `$GOPATH/src/github.com/hashicorp/packer`. 70 71 4. When working on packer `cd $GOPATH/src/github.com/hashicorp/packer` so you 72 can run `make` and easily access other files. Run `make help` to get 73 information about make targets. 74 75 5. Make your changes to the Packer source. You can run `make` in 76 `$GOPATH/src/github.com/hashicorp/packer` to run tests and build the packer 77 binary. Any compilation errors will be shown when the binaries are 78 rebuilding. If you don't have `make` you can simply run `go build -o bin/packer .` from the project root. 79 80 6. After running building packer successfully, use 81 `$GOPATH/src/github.com/hashicorp/packer/bin/packer` to build a machine and 82 verify your changes work. For instance: `$GOPATH/src/github.com/hashicorp/packer/bin/packer build template.json`. 83 84 7. If everything works well and the tests pass, run `go fmt` on your code 85 before submitting a pull-request. 86 87 ### Opening an Pull Request 88 89 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. 90 91 For example, my github username is `cbednarski` so I would do the following: 92 93 git checkout -b f-my-feature 94 // develop a patch 95 git push https://github.com/cbednarski/packer f-my-feature 96 97 From there, open your fork in your browser to open a new pull-request. 98 99 **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. 100 101 ### Tips for Working on Packer 102 103 #### Working on forks 104 105 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": 106 107 1. Navigate to $GOPATH/src/github.com/hashicorp/packer 108 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`. 109 3. Checkout a feature branch: `git checkout -b new-feature` 110 4. Make changes 111 5. (Optional) Push your changes to the fork: `git push -u <name of remote> new-feature` 112 113 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. 114 115 #### Govendor 116 117 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. 118 119 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. 120 121 Use `govendor fetch <project>` to add dependencies to the project. See 122 [govendor quick 123 start](https://github.com/kardianos/govendor#quick-start-also-see-the-faq) for 124 examples. 125 126 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. 127 128 #### Running Unit Tests 129 130 You can run tests for individual packages using commands like this: 131 132 $ make test TEST=./builder/amazon/... 133 134 #### Running Acceptance Tests 135 136 Packer has [acceptance tests](https://en.wikipedia.org/wiki/Acceptance_testing) 137 for various builders. These typically require an API key (AWS, GCE), or 138 additional software to be installed on your computer (VirtualBox, VMware). 139 140 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 141 acceptance tests. 142 143 **Warning:** The acceptance tests create/destroy/modify *real resources*, which 144 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. 145 146 To run the acceptance tests, invoke `make testacc`: 147 148 $ make testacc TEST=./builder/amazon/ebs 149 ... 150 151 The `TEST` variable lets you narrow the scope of the acceptance tests to a 152 specific package / folder. The `TESTARGS` variable is recommended to filter 153 down to a specific resource to test, since testing all of them at once can 154 sometimes take a very long time. 155 156 To run only a specific test, use the `-run` argument: 157 158 ``` 159 make testacc TEST=./builder/amazon/ebs TESTARGS="-run TestBuilderAcc_forceDeleteSnapshot" 160 ``` 161 162 Acceptance tests typically require other environment variables to be set for 163 things such as API tokens and keys. Each test should error and tell you which 164 credentials are missing, so those are not documented here.