github.com/rothwerx/packer@v0.9.0/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.
    55  
    56  1. [Download](https://golang.org/dl) and install Go. Go 1.6 or higher is
    57     preferred. Packer _may_ work with versions of Go older than 1.5 but these
    58     are not supported.
    59  
    60  2. Set and export the `GOPATH` environment variable and update your `PATH`. For
    61     example, you can add to your `.bash_profile`. If you're using Go 1.5 also
    62     set `GO15VENDOREXPERIMENT`. This is not necessary for Go 1.6 and up.
    63  
    64      ```
    65      export GOPATH=$HOME/Documents/golang
    66      export GO15VENDOREXPERIMENT=1
    67      export PATH=$PATH:$GOPATH/bin
    68      ```
    69  
    70  3. Download the Packer source (and its dependencies) by running `go get
    71     github.com/mitchellh/packer`. This will download the Packer source to
    72     `$GOPATH/src/github.com/mitchellh/packer`.
    73  
    74  4. When working on packer `cd $GOPATH/src/github.com/mitchellh/packer` so you
    75     can run make and easily access other files.
    76  
    77  5. Make your changes to the Packer source. You can run `make` in
    78     `$GOPATH/src/github.com/mitchellh/packer` to run tests and build the packer
    79     binary. Any compilation errors will be shown when the binaries are
    80     rebuilding.
    81  
    82  6. After running `make` successfully, use
    83     `$GOPATH/src/github.com/mitchellh/packer/bin/packer` to build a machine and
    84     verify your changes work.
    85  
    86  7. If everything works well and the tests pass, run `go fmt` on your code
    87     before submitting a pull-request.
    88  
    89  ### Tips for Working on Packer
    90  
    91  #### Godeps
    92  
    93  If you are submitting a change that requires a change in dependencies, DO NOT update the `vendor/` folder. This keeps the PR smaller and easier to review. Instead, please indicate which upstream has changed and which version we should be using. You _may_ do this using `Godeps/Godeps.json` but this is not required.
    94  
    95  #### Running Unit Tests
    96  
    97  You can run tests for individual packages using commands like this:
    98  
    99      $ make test TEST=./builder/amazon/...
   100  
   101  #### Running Acceptance Tests
   102  
   103  Packer has [acceptance tests](https://en.wikipedia.org/wiki/Acceptance_testing)
   104  for various builders. These typically require an API key (AWS, GCE), or
   105  additional software to be installed on your computer (VirtualBox, VMware).
   106  
   107  If you're working on a feature of a builder or a new builder and want verify it
   108  is functioning (and also hasn't broken anything else), we recommend running the
   109  acceptance tests.
   110  
   111  **Warning:** The acceptance tests create/destroy/modify *real resources*, which
   112  may incur real costs in some cases. In the presence of a bug, it is technically
   113  possible that broken backends could leave dangling data behind. Therefore,
   114  please run the acceptance tests at your own risk. At the very least, we
   115  recommend running them in their own private account for whatever builder you're
   116  testing.
   117  
   118  To run the acceptance tests, invoke `make testacc`:
   119  
   120      $ make testacc TEST=./builder/amazon/ebs
   121      ...
   122  
   123  The `TEST` variable lets you narrow the scope of the acceptance tests to a
   124  specific package / folder. The `TESTARGS` variable is recommended to filter
   125  down to a specific resource to test, since testing all of them at once can
   126  sometimes take a very long time.
   127  
   128  Acceptance tests typically require other environment variables to be set for
   129  things such as access keys. The test itself should error early and tell you
   130  what to set, so it is not documented here.