github.com/umeshredd/helm@v3.0.0-alpha.1+incompatible/docs/developers.md (about)

     1  # Developers Guide
     2  
     3  This guide explains how to set up your environment for developing on
     4  Helm.
     5  
     6  ## Prerequisites
     7  
     8  - The latest version of Go
     9  - The latest version of Dep
    10  - A Kubernetes cluster w/ kubectl (optional)
    11  - Git
    12  
    13  ## Building Helm
    14  
    15  We use Make to build our programs. The simplest way to get started is:
    16  
    17  ```console
    18  $ make bootstrap build
    19  ```
    20  
    21  NOTE: This will fail if not running from the path `$GOPATH/src/helm.sh/helm`. The
    22  directory `helm.sh` should not be a symlink or `build` will not find the relevant
    23  packages.
    24  
    25  This will build both Helm and the Helm library. `make bootstrap` will attempt to
    26  install certain tools if they are missing.
    27  
    28  To run all the tests (without running the tests for `vendor/`), run
    29  `make test`.
    30  
    31  To run Helm locally, you can run `bin/helm`.
    32  
    33  - Helm is known to run on macOS and most Linuxes, including Alpine.
    34  
    35  ### Man pages
    36  
    37  Man pages and Markdown documentation are not pre-built in `docs/` but you can
    38  generate the documentation using `make docs`.
    39  
    40  To expose the Helm man pages to your `man` client, you can put the files in your
    41  `$MANPATH`:
    42  
    43  ```
    44  $ export MANPATH=$GOPATH/src/helm.sh/helm/docs/man:$MANPATH
    45  $ man helm
    46  ```
    47  
    48  
    49  ## Docker Images
    50  
    51  To build Docker images, use `make docker-build`.
    52  
    53  Pre-build images are already available in the official Kubernetes Helm
    54  GCR registry.
    55  
    56  ## Running a Local Cluster
    57  
    58  For development, we highly recommend using the
    59  [Kubernetes Minikube](https://github.com/kubernetes/minikube)
    60  developer-oriented distribution.
    61  
    62  ## Contribution Guidelines
    63  
    64  We welcome contributions. This project has set up some guidelines in
    65  order to ensure that (a) code quality remains high, (b) the project
    66  remains consistent, and (c) contributions follow the open source legal
    67  requirements. Our intent is not to burden contributors, but to build
    68  elegant and high-quality open source code so that our users will benefit.
    69  
    70  Make sure you have read and understood the main CONTRIBUTING guide:
    71  
    72  https://github.com/helm/helm/blob/master/CONTRIBUTING.md
    73  
    74  ### Structure of the Code
    75  
    76  The code for the Helm project is organized as follows:
    77  
    78  - The individual programs are located in `cmd/`. Code inside of `cmd/`
    79    is not designed for library re-use.
    80  - Shared libraries are stored in `pkg/`.
    81  - The `scripts/` directory contains a number of utility scripts. Most of these
    82    are used by the CI/CD pipeline.
    83  - The `docs/` folder is used for documentation and examples.
    84  
    85  Go dependencies are managed with
    86  [Dep](https://github.com/golang/dep) and stored in the
    87  `vendor/` directory.
    88  
    89  ### Git Conventions
    90  
    91  We use Git for our version control system. The `master` branch is the
    92  home of the current development candidate. Releases are tagged.
    93  
    94  We accept changes to the code via GitHub Pull Requests (PRs). One
    95  workflow for doing this is as follows:
    96  
    97  1. Go to your `$GOPATH/src` directory, then `mkdir helm.sh; cd helm.sh` and `git clone` the
    98     `github.com/helm/helm` repository.
    99  2. Fork that repository into your GitHub account
   100  3. Add your repository as a remote for `$GOPATH/src/helm.sh/helm`
   101  4. Create a new working branch (`git checkout -b feat/my-feature`) and
   102     do your work on that branch.
   103  5. When you are ready for us to review, push your branch to GitHub, and
   104     then open a new pull request with us.
   105  
   106  For Git commit messages, we follow the [Semantic Commit Messages](http://karma-runner.github.io/0.13/dev/git-commit-msg.html):
   107  
   108  ```
   109  fix(helm): add --foo flag to 'helm install'
   110  
   111  When 'helm install --foo bar' is run, this will print "foo" in the
   112  output regardless of the outcome of the installation.
   113  
   114  Closes #1234
   115  ```
   116  
   117  Common commit types:
   118  
   119  - fix: Fix a bug or error
   120  - feat: Add a new feature
   121  - docs: Change documentation
   122  - test: Improve testing
   123  - ref: refactor existing code
   124  
   125  Common scopes:
   126  
   127  - helm: The Helm CLI
   128  - pkg/lint: The lint package. Follow a similar convention for any
   129    package
   130  - `*`: two or more scopes
   131  
   132  Read more:
   133  - The [Deis Guidelines](https://github.com/deis/workflow/blob/master/src/contributing/submitting-a-pull-request.md)
   134    were the inspiration for this section.
   135  - Karma Runner [defines](http://karma-runner.github.io/0.13/dev/git-commit-msg.html) the semantic commit message idea.
   136  
   137  ### Go Conventions
   138  
   139  We follow the Go coding style standards very closely. Typically, running
   140  `go fmt` will make your code beautiful for you.
   141  
   142  We also typically follow the conventions recommended by `go lint` and
   143  `gometalinter`. Run `make test-style` to test the style conformance.
   144  
   145  Read more:
   146  
   147  - Effective Go [introduces formatting](https://golang.org/doc/effective_go.html#formatting).
   148  - The Go Wiki has a great article on [formatting](https://github.com/golang/go/wiki/CodeReviewComments).