Updating CONTRIBUTING.md

Fixing merge conflict created in #6133.

Signed-off-by: clouderati <35942204+clouderati@users.noreply.github.com>
This commit is contained in:
clouderati 2018-12-12 17:02:37 +00:00
parent 6ac0c4b882
commit 3a38ff928e
1 changed files with 320 additions and 314 deletions

View File

@ -1,314 +1,320 @@
# Contributing to Harbor # Contributing to Harbor
## Welcome ## Welcome
Welcome to Harbor! This guide provides information on filing issues and guidelines for open source contributors. **Please leave comments / suggestions if you find something is missing or incorrect.** Welcome to Harbor! This guide provides information on filing issues and guidelines for open source contributors. **Please leave comments / suggestions if you find something is missing or incorrect.**
Contributors are encouraged to collaborate using the following resources in addition to the GitHub [issue tacker](https://github.com/goharbor/harbor/issues): Contributors are encouraged to collaborate using the following resources in addition to the GitHub [issue tacker](https://github.com/goharbor/harbor/issues):
**Twitter:** [@project_harbor](https://twitter.com/project_harbor) **Twitter:** [@project_harbor](https://twitter.com/project_harbor)
**User Group:** Join Harbor user email group: [harbor-users@googlegroups.com](https://groups.google.com/forum/#!forum/harbor-users) to get update of Harbor's news, features, releases, or to provide suggestion and feedback. To subscribe, send an email to [harbor-users+subscribe@googlegroups.com](mailto:harbor-users+subscribe@googlegroups.com) . **User Group:** Join Harbor user email group: [harbor-users@googlegroups.com](https://groups.google.com/forum/#!forum/harbor-users) to get update of Harbor's news, features, releases, or to provide suggestion and feedback. To subscribe, send an email to [harbor-users+subscribe@googlegroups.com](mailto:harbor-users+subscribe@googlegroups.com) .
**Developer Group:** Join Harbor developer group: [harbor-dev@googlegroups.com](https://groups.google.com/forum/#!forum/harbor-dev) for discussion on Harbor development and contribution. To subscribe, send an email to [harbor-dev+subscribe@googlegroups.com](mailto:harbor-dev+subscribe@googlegroups.com). **Developer Group:** Join Harbor developer group: [harbor-dev@googlegroups.com](https://groups.google.com/forum/#!forum/harbor-dev) for discussion on Harbor development and contribution. To subscribe, send an email to [harbor-dev+subscribe@googlegroups.com](mailto:harbor-dev+subscribe@googlegroups.com).
**Slack:** Join Harbor's community for discussion and ask questions: [Cloud Native Computing Foundation](https://slack.cncf.io/), channel: #harbor and #harbor-dev **Slack:** Join Harbor's community for discussion and ask questions: [Cloud Native Computing Foundation](https://slack.cncf.io/), channel: #harbor and #harbor-dev
## Getting Started ## Getting Started
### Fork Repository ### Fork Repository
Fork the Harbor repository on GitHub to your personal account. Fork the Harbor repository on GitHub to your personal account.
``` ```
#Set golang environment #Set golang environment
export GOPATH=$HOME/go export GOPATH=$HOME/go
mkdir -p $GOPATH/src/github.com/goharbor mkdir -p $GOPATH/src/github.com/goharbor
#Get code #Get code
go get github.com/goharbor/harbor go get github.com/goharbor/harbor
cd $GOPATH/src/github.com/goharbor/harbor cd $GOPATH/src/github.com/goharbor/harbor
#Track repository under your personal account #Track repository under your personal account
git config push.default nothing # Anything to avoid pushing to vmware/harbor by default git config push.default nothing # Anything to avoid pushing to goharbor/harbor by default
git remote rename origin vmware git remote rename origin goharbor
git remote add $USER git@github.com:$USER/harbor.git git remote add $USER git@github.com:$USER/harbor.git
git fetch $USER git fetch $USER
``` ```
**NOTES:** Note that GOPATH can be any directory, the example above uses $HOME/go. Change $USER above to your own GitHub username. **NOTES:** Note that GOPATH can be any directory, the example above uses $HOME/go. Change $USER above to your own GitHub username.
To build the project, please refer the [build](docs/compile_guide.md) guideline. To build the project, please refer the [build](docs/compile_guide.md) guideline.
### Repository Structure ### Repository Structure
Here is the basic structure of the harbor code base. Some of the key folders / files are commented for your references. Here is the basic structure of the harbor code base. Some of the key folders / files are commented for your references.
``` ```
. .
... ...
├── Makefile #Make file for compile and build code ├── Makefile # Make file for compile and build code
├── contrib #Contain documents, scripts, and other helpful things which are contributed by the community ├── contrib # Contain documents, scripts, and other helpful things which are contributed by the community
├── docs #Keep documents here ├── docs # Keep documents here
├── make #Resource for building and setting up Harbor environment ├── make # Resource for building and setting up Harbor environment
... ...
├── src #Source code folder ├── src # Source code folder
├── tests #Test cases for API / e2e testings ├── tests # Test cases for API / e2e testings
└── tools #Keep supporting tools └── tools # Keep supporting tools
... ...
``` ```
The folder graph below shows the structure of the source code folder `harbor/src`, which will be your primary working directory. The key folders are also commented. The folder graph below shows the structure of the source code folder `harbor/src`, which will be your primary working directory. The key folders are also commented.
``` ```
. .
├── adminserver # Source code for the admin server component ├── adminserver # Source code for the admin server component
│   ├── api │   ├── api
│   ├── auth │   ├── auth
│   ├── client │   ├── client
│   ├── handlers │   ├── handlers
│   ├── systemcfg │   ├── systemcfg
│   └── systeminfo │   └── systeminfo
├── common # Source code for some general components like dao etc. ├── common # Source code for some general components like dao etc.
│   ├── api │   ├── api
│   ├── config │   ├── config
│   ├── dao │   ├── dao
│   ├── models │   ├── models
│   ├── notifier │   ├── notifier
│   ├── scheduler │   ├── scheduler
│   ├── secret │   ├── secret
│   ├── security │   ├── security
│   └── utils │   └── utils
├── jobservice # Source code for the job service component ├── jobservice # Source code for the job service component
│   ├── api │   ├── api
│   ├── config │   ├── config
│   ├── job │   ├── job
│   ├── replication │   ├── replication
│   ├── scan │   ├── scan
│   └── utils │   └── utils
├── ui # Source code for the harbor service component ├── ui # Source code for the harbor service component
│   ├── api │   ├── api
│   ├── auth │   ├── auth
│   ├── config │   ├── config
│   ├── controllers │   ├── controllers
│   ├── filter │   ├── filter
│   ├── promgr │   ├── promgr
│   ├── proxy │   ├── proxy
│   ├── service │   ├── service
│   ├── static │   ├── static
│   ├── utils │   ├── utils
│   └── views │   └── views
├── portal # The code of harbor web UI ├── portal # The code of harbor web UI
│   ├── e2e │   ├── e2e
│   ├── lib # Source code of @harbor/ui npm library which includes the main UI components of web UI │   ├── lib # Source code of @harbor/ui npm library which includes the main UI components of web UI
│   └── src # General web page UI code of Harbor │   └── src # General web page UI code of Harbor
└── vendor # Go code dependencies └── vendor # Go code dependencies
├── github.com ├── github.com
├── golang.org ├── golang.org
├── google.golang.org ├── google.golang.org
└── gopkg.in └── gopkg.in
``` ```
### Setup Development Environment ### Setup Development Environment
#### Go #### Go
Harbor backend is written in [Go](http://golang.org/). If you don't have a Harbor backend service development environment, please [set one up](https://golang.org/doc/install). Harbor backend is written in [Go](http://golang.org/). If you don't have a Harbor backend service development environment, please [set one up](https://golang.org/doc/install).
| Harbor | Requires Go | | Harbor | Requires Go |
|----------|---------------| |----------|---------------|
| 1.1 | 1.7.3 | | 1.1 | 1.7.3 |
| 1.2 | 1.7.3 | | 1.2 | 1.7.3 |
| 1.3 | 1.9.2 | | 1.3 | 1.9.2 |
| 1.4 | 1.9.2 | | 1.4 | 1.9.2 |
| 1.5 | 1.9.2 |
Ensure your GOPATH and PATH have been configured in accordance with the Go environment instructions. | 1.6 | 1.9.2 |
| 1.6 | tbd |
**Dependency Management:** Harbor uses [dep](https://github.com/golang/dep) for dependency management of go code. The official maintainers will take the responsibility for managing the code in `vendor` directory. Please don't try to submit a PR to update the dependency code, open an issue instead. If your PR requires a change in the vendor code please make sure you discuss it with the maintainers in advance.
Ensure your GOPATH and PATH have been configured in accordance with the Go environment instructions.
#### Web
**Dependency Management:** Harbor uses [dep](https://github.com/golang/dep) for dependency management of go code. The official maintainers will take the responsibility for managing the code in `vendor` directory. Please don't try to submit a PR to update the dependency code, open an issue instead. If your PR requires a change in the vendor code please make sure you discuss it with the maintainers in advance.
Harbor web UI is built based on [Clarity](https://vmware.github.io/clarity/) and [Angular](https://angular.io/) web framework. To setup web UI development environment, please make sure the [npm](https://www.npmjs.com/get-npm) tool is installed first.
#### Web
| Harbor | Requires Angular | Requires Clarity |
|----------|--------------------|--------------------| Harbor web UI is built based on [Clarity](https://vmware.github.io/clarity/) and [Angular](https://angular.io/) web framework. To setup web UI development environment, please make sure the [npm](https://www.npmjs.com/get-npm) tool is installed first.
| 1.1 | 2.4.1 | 0.8.7 |
| 1.2 | 4.1.3 | 0.9.8 | | Harbor | Requires Angular | Requires Clarity |
| 1.3 | 4.3.0 | 0.10.17 | |----------|--------------------|--------------------|
| 1.4 | | | | 1.1 | 2.4.1 | 0.8.7 |
| 1.2 | 4.1.3 | 0.9.8 |
**Npm Package Dependency:** Run the following commands to restore the package dependencies. | 1.3 | 4.3.0 | 0.10.17 |
``` | 1.4 | 4.3.0 | 0.10.17 |
#For the web UI | 1.5 | 4.3.0 | 0.10.27 |
cd $REPO_DIR/src/portal | 1.6 | 4.3.0 | 0.10.27 |
npm install
**npm Package Dependency:** Run the following commands to restore the package dependencies.
#For the UI library ```
cd $REPO_DIR/src/portal/lib #For the web UI
npm install cd $REPO_DIR/src/portal
``` npm install
#For the UI library
To run the code, please refer to the [build](docs/compile_guide.md) guideline. cd $REPO_DIR/src/portal/lib
npm install
## Contribute Workflow ```
PR are always welcome, even if they only contain small fixes like typos or a few lines of code. If there will be a significant effort, please document it as an issue and get a discussion going before starting to work on it.
To run the code, please refer to the [build](docs/compile_guide.md) guideline.
Please submit a PR broken down into small changes bit by bit. A PR consisting of a lot features and code changes may be hard to review. It is recommended to submit PRs in an incremental fashion.
## Contribute Workflow
The graphic shown below describes the overall workflow about how to contribute code to Harbor repository.
![contribute workflow](docs/img/workflow.png) PR are always welcome, even if they only contain small fixes like typos or a few lines of code. If there will be a significant effort, please document it as an issue and get a discussion going before starting to work on it.
### Fork and clone Please submit a PR broken down into small changes bit by bit. A PR consisting of a lot features and code changes may be hard to review. It is recommended to submit PRs in an incremental fashion.
Fork the Harbor repository and clone the code to your local workspace. Per Go's [workspace instructions](https://golang.org/doc/code.html#Workspaces), place Harbor's code on your `GOPATH`. Refer to section [Fork Repository](#fork-repository) for details. The graphic shown below describes the overall workflow about how to contribute code to Harbor repository.
![contribute workflow](docs/img/workflow.png)
Define a local working directory:
``` ### Fork and clone
working_dir=$GOPATH/src/github.com/goharbor
``` Fork the Harbor repository and clone the code to your local workspace. Per Go's [workspace instructions](https://golang.org/doc/code.html#Workspaces), place Harbor's code on your `GOPATH`. Refer to section [Fork Repository](#fork-repository) for details.
Set user to match your github profile name: Define a local working directory:
``` ```
user={your github profile name} working_dir=$GOPATH/src/github.com/goharbor
``` ```
Both `$working_dir` and `$user` are mentioned in the figure above. Set user to match your github profile name:
```
### Branch user={your github profile name}
Changes should be made on your own fork in a new branch. The branch should be named `XXX-description` where XXX is the number of the issue. PR should be rebased on top of master without multiple branches mixed into the PR. If your PR do not merge cleanly, use commands listed below to get it up to date. ```
``` Both `$working_dir` and `$user` are mentioned in the figure above.
#vmware is the origin upstream
### Branch
cd $working_dir/kubernetes Changes should be made on your own fork in a new branch. The branch should be named `XXX-description` where XXX is the number of the issue. PR should be rebased on top of master without multiple branches mixed into the PR. If your PR do not merge cleanly, use commands listed below to get it up to date.
git fetch vmware
git checkout master ```
git rebase vmware/master #goharbor is the origin upstream
```
cd $working_dir/kubernetes
Branch from the updated `master` branch: git fetch goharbor
git checkout master
``` git rebase goharbor/master
git checkout -b my_feature master ```
```
Branch from the updated `master` branch:
### Develop, Build and Test
```
Write code on the new branch in your fork. The coding style used in Harbor is suggested by the Golang community. See the [style doc](https://github.com/golang/go/wiki/CodeReviewComments) for details. git checkout -b my_feature master
```
Try to limit column width to 120 characters for both code and markdown documents such as this one.
### Develop, Build and Test
Always run [golint](https://github.com/golang/lint) on source code before
committing your changes. Write code on the new branch in your fork. The coding style used in Harbor is suggested by the Golang community. See the [style doc](https://github.com/golang/go/wiki/CodeReviewComments) for details.
```
#Install fgt and golint Try to limit column width to 120 characters for both code and markdown documents such as this one.
go get -u golang.org/x/lint/golint Always run [golint](https://github.com/golang/lint) on source code before
go get github.com/GeertJohan/fgt committing your changes.
```
#In the #working_dir/harbor, run #Install fgt and golint
go list ./... | grep -v -E 'vendor|tests' | xargs -L1 fgt golint go get -u golang.org/x/lint/golint
go get github.com/GeertJohan/fgt
```
#In the #working_dir/harbor, run
Unit test cases should be added to cover the new code. Unit test framework for backend services is using [go testing](https://golang.org/doc/code.html#Testing). The UI library test framework is built based on [Jasmine](http://jasmine.github.io/2.4/introduction.html) and [Karma](https://karma-runner.github.io/1.0/index.html), please refer to [Angular Testing](https://angular.io/guide/testing) for more details.
go list ./... | grep -v -E 'vendor|tests' | xargs -L1 fgt golint
Run go test cases:
``` ```
#cd #working_dir/src/[package]
go test -v ./... Unit test cases should be added to cover the new code. Unit test framework for backend services is using [go testing](https://golang.org/doc/code.html#Testing). The UI library test framework is built based on [Jasmine](http://jasmine.github.io/2.4/introduction.html) and [Karma](https://karma-runner.github.io/1.0/index.html), please refer to [Angular Testing](https://angular.io/guide/testing) for more details.
```
Run go test cases:
Run UI library test cases: ```
``` #cd #working_dir/src/[package]
#cd #working_dir/src/portal/lib go test -v ./...
npm run test ```
```
Run UI library test cases:
To build code, please refer to [build](docs/compile_guide.md) guideline. ```
#cd #working_dir/src/portal/lib
### Keep sync with upstream npm run test
```
Once your branch gets out of sync with the vmware/master branch, use the following commands to update:
``` To build code, please refer to [build](docs/compile_guide.md) guideline.
git checkout my_feature
git fetch -a ### Keep sync with upstream
git rebase vmware/master
```
``` Once your branch gets out of sync with the goharbor/master branch, use the following commands to update:
```
Please don't use `git pull` instead of the above `fetch / rebase`. `git pull` does a merge, which leaves merge commits. These make the commit history messy and violate the principle that commits ought to be individually understandable and useful (see below). You can also consider changing your `.git/config` file via git config `branch.autoSetupRebase` always to change the behavior of `git pull`. git checkout my_feature
git fetch -a
### Commit git rebase goharbor/master
As Harbor has integrated the [DCO (Developer Certificate of Origin)](https://probot.github.io/apps/dco/) check tool, contributors are required to sign-off that they adhere to those requirements by adding a `Signed-off-by` line to the commit messages. Git has even provided a `-s` command line option to append that automatically to your commit messages, please use it when you commit your changes. ```
```bash Please don't use `git pull` instead of the above `fetch / rebase`. `git pull` does a merge, which leaves merge commits. These make the commit history messy and violate the principle that commits ought to be individually understandable and useful (see below). You can also consider changing your `.git/config` file via git config `branch.autoSetupRebase` always to change the behavior of `git pull`.
$ git commit -s -m 'This is my commit message'
``` ### Commit
Commit your changes if they're ready: As Harbor has integrated the [DCO (Developer Certificate of Origin)](https://probot.github.io/apps/dco/) check tool, contributors are required to sign-off that they adhere to those requirements by adding a `Signed-off-by` line to the commit messages. Git has even provided a `-s` command line option to append that automatically to your commit messages, please use it when you commit your changes.
```
#git add -A ```bash
git commit -s #-a $ git commit -s -m 'This is my commit message'
git push --force-with-lease $user my_feature ```
```
Commit your changes if they're ready:
The commit message should follow the convention on [How to Write a Git Commit Message](http://chris.beams.io/posts/git-commit/). Be sure to include any related GitHub issue references in the commit message. See [GFM syntax](https://guides.github.com/features/mastering-markdown/#GitHub-flavored-markdown) for referencing issues and commits. ```
#git add -A
To help write conforming commit messages, it is recommended to set up the [git-good-commit](https://github.com/tommarshall/git-good-commit) commit hook. Run this command in the Harbor repo's root directory: git commit -s #-a
git push --force-with-lease $user my_feature
``` ```
curl https://cdn.rawgit.com/tommarshall/git-good-commit/v0.6.1/hook.sh > .git/hooks/commit-msg && chmod +x .git/hooks/commit-msg
``` The commit message should follow the convention on [How to Write a Git Commit Message](http://chris.beams.io/posts/git-commit/). Be sure to include any related GitHub issue references in the commit message. See [GFM syntax](https://guides.github.com/features/mastering-markdown/#GitHub-flavored-markdown) for referencing issues and commits.
### Automated Testing To help write conforming commit messages, it is recommended to set up the [git-good-commit](https://github.com/tommarshall/git-good-commit) commit hook. Run this command in the Harbor repo's root directory:
Once your pull request has been opened, harbor will run two CI pipelines against it.
1. In the travis CI, your source code will be checked via `golint`, `go vet` and `go race` that makes sure the code is readable, safe and correct. Also all of unit tests will be triggered via `go test` against the pull request. What you need to pay attention to is the travis result and the coverage report. ```
* If any failure in travis, you need to figure out whether it is introduced by your commits. curl https://cdn.rawgit.com/tommarshall/git-good-commit/v0.6.1/hook.sh > .git/hooks/commit-msg && chmod +x .git/hooks/commit-msg
* If the coverage dramatic decline, you need to commit unit test to coverage your code. ```
2. In the drone CI, the E2E test will be triggered against the pull request. The pipeline is about to build and install harbor from source code, then to run four very basic E2E tests to validate the basic functionalities of harbor, like:
* Registry Basic Verification, to validate the image can be pulled and pushed successful. ### Automated Testing
* Clair Basic Verification, to validate the image can be scanned successful. Once your pull request has been opened, harbor will run two CI pipelines against it.
* Notary Basic Verification, to validate the image can be signed successful. 1. In the travis CI, your source code will be checked via `golint`, `go vet` and `go race` that makes sure the code is readable, safe and correct. Also all of unit tests will be triggered via `go test` against the pull request. What you need to pay attention to is the travis result and the coverage report.
* Ldap Basic Verification, to validate harbor can work in LDAP environment. * If any failure in travis, you need to figure out whether it is introduced by your commits.
* If the coverage dramatic decline, you need to commit unit test to coverage your code.
### Push and Create PR 2. In the drone CI, the E2E test will be triggered against the pull request. The pipeline is about to build and install harbor from source code, then to run four very basic E2E tests to validate the basic functionalities of harbor, like:
When ready for review, push your branch to your fork repository on `github.com`: * Registry Basic Verification, to validate the image can be pulled and pushed successful.
``` * Clair Basic Verification, to validate the image can be scanned successful.
git push --force-with-lease $user my_feature * Notary Basic Verification, to validate the image can be signed successful.
* Ldap Basic Verification, to validate harbor can work in LDAP environment.
```
### Push and Create PR
Then visit your fork at https://github.com/$user/harbor and click the `Compare & Pull Request` button next to your `my_feature` branch to create a new pull request (PR). Description of a pull request should refer to all the issues that it addresses. Remember to put a reference to issues (such as `Closes #XXX` and `Fixes #XXX`) in commits so that the issues can be closed when the PR is merged. When ready for review, push your branch to your fork repository on `github.com`:
```
Once your pull request has been opened it will be assigned to one or more reviewers. Those reviewers will do a thorough code review, looking for correctness, bugs, opportunities for improvement, documentation and comments, and style. git push --force-with-lease $user my_feature
Commit changes made in response to review comments to the same branch on your fork. ```
## Reporting issues Then visit your fork at https://github.com/$user/harbor and click the `Compare & Pull Request` button next to your `my_feature` branch to create a new pull request (PR). Description of a pull request should refer to all the issues that it addresses. Remember to put a reference to issues (such as `Closes #XXX` and `Fixes #XXX`) in commits so that the issues can be closed when the PR is merged.
It is a great way to contribute to Harbor by reporting an issue. Well-written and complete bug reports are always welcome! Please open an issue on Github and follow the template to fill in required information. Once your pull request has been opened it will be assigned to one or more reviewers. Those reviewers will do a thorough code review, looking for correctness, bugs, opportunities for improvement, documentation and comments, and style.
Before opening any issue, please look up the existing [issues](https://github.com/vmware/harbor/issues) to avoid submitting a duplication. Commit changes made in response to review comments to the same branch on your fork.
If you find a match, you can "subscribe" to it to get notified on updates. If you have additional helpful information about the issue, please leave a comment.
## Reporting issues
When reporting issues, always include:
It is a great way to contribute to Harbor by reporting an issue. Well-written and complete bug reports are always welcome! Please open an issue on Github and follow the template to fill in required information.
* Version of docker engine and docker-compose
* Configuration files of Harbor Before opening any issue, please look up the existing [issues](https://github.com/goharbor/harbor/issues) to avoid submitting a duplication.
* Log files in /var/log/harbor/ If you find a match, you can "subscribe" to it to get notified on updates. If you have additional helpful information about the issue, please leave a comment.
Because the issues are open to the public, when submitting the log and configuration files, be sure to remove any sensitive information, e.g. user name, password, IP address, and company name. You can When reporting issues, always include:
replace those parts with "REDACTED" or other strings like "****".
* Version of docker engine and docker-compose
Be sure to include the steps to reproduce the problem if applicable. It can help us understand and fix your issue faster. * Configuration files of Harbor
* Log files in /var/log/harbor/
## Documenting
Because the issues are open to the public, when submitting the log and configuration files, be sure to remove any sensitive information, e.g. user name, password, IP address, and company name. You can
Update the documentation if you are creating or changing features. Good documentation is as important as the code itself. replace those parts with "REDACTED" or other strings like "****".
The main location for the document is the `docs/` folder. The images referred in documents can be placed in `docs/img`. Be sure to include the steps to reproduce the problem if applicable. It can help us understand and fix your issue faster.
Documents are written with Markdown text. See [Writing on GitHub](https://help.github.com/categories/writing-on-github/) for more details. ## Documenting
## Design new features Update the documentation if you are creating or changing features. Good documentation is as important as the code itself.
You can propose new designs for existing Harbor features. You can also design The main location for the document is the `docs/` folder. The images referred in documents can be placed in `docs/img`.
entirely new features. Please do open an issue on Github for discussion first. This is necessary to ensure the overall architecture is consistent and to avoid duplicated work in the roadmap.
Documents are written with Markdown text. See [Writing on GitHub](https://help.github.com/categories/writing-on-github/) for more details.
## Design new features
You can propose new designs for existing Harbor features. You can also design
entirely new features. Please do open an issue on Github for discussion first. This is necessary to ensure the overall architecture is consistent and to avoid duplicated work in the roadmap.