github.com/rahart/packer@v0.12.2-0.20161229105310-282bb6ad370f/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.6. 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/mitchellh/packer`. This will download the Packer source to
    69     `$GOPATH/src/github.com/mitchellh/packer`.
    70  
    71  4. When working on packer `cd $GOPATH/src/github.com/mitchellh/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/mitchellh/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/mitchellh/packer/bin/packer` to build a machine and
    82     verify your changes work. For instance: `$GOPATH/src/github.com/mitchellh/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/mitchellh/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  #### Govendor
   104  
   105  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.
   106  
   107  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.
   108  
   109  Use `govendor fetch <project>` to add dependencies to the project. See
   110  [govendor quick
   111  start](https://github.com/kardianos/govendor#quick-start-also-see-the-faq) for
   112  examples.
   113  
   114  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.
   115  
   116  #### Running Unit Tests
   117  
   118  You can run tests for individual packages using commands like this:
   119  
   120      $ make test TEST=./builder/amazon/...
   121  
   122  #### Running Acceptance Tests
   123  
   124  Packer has [acceptance tests](https://en.wikipedia.org/wiki/Acceptance_testing)
   125  for various builders. These typically require an API key (AWS, GCE), or
   126  additional software to be installed on your computer (VirtualBox, VMware).
   127  
   128  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
   129  acceptance tests.
   130  
   131  **Warning:** The acceptance tests create/destroy/modify *real resources*, which
   132  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.
   133  
   134  To run the acceptance tests, invoke `make testacc`:
   135  
   136      $ make testacc TEST=./builder/amazon/ebs
   137      ...
   138  
   139  The `TEST` variable lets you narrow the scope of the acceptance tests to a
   140  specific package / folder. The `TESTARGS` variable is recommended to filter
   141  down to a specific resource to test, since testing all of them at once can
   142  sometimes take a very long time.
   143  
   144  Acceptance tests typically require other environment variables to be set for
   145  things such as API tokens and keys. Each test should error and tell you which
   146  credentials are missing, so those are not documented here.