Upstream
/
harbor
mirror of https://github.com/goharbor/harbor.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

docs(readme): fix syntax errors in the document (#18113)

This commit is contained in:
Fish-pro 2023-01-30 18:08:47 +08:00 committed by GitHub
parent 341cc4510d
commit ca5fed3e2c
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
6 changed files with 15 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
ADOPTERS.md
View File

@ -75,7 +75,7 @@ and manages more than 3,000 images.
CI/CD pipeline for more than a year housing hundreds of images for various
environments.
**AWN:** Utilizes Harbor as a secure image repository for all of internal
**AWN:** Utilizes Harbor as a secure image repository for all internal
container-based workloads. Harbor provides developers and sysadmins a secure
and easy-to-use repository. AWN leverages the image vulnerability scanning
feature within Harbor before deploying images into production.

10
CONTRIBUTING.md
View File

@ -11,7 +11,7 @@ Contributors are encouraged to collaborate using the following resources in addi
* [Bi-weekly public community meetings][community-meetings]
* Catch up with [past meetings on YouTube][past-meetings]
* Chat with us on the CNCF Slack ([get an invite here][cncf-slack] )
* Chat with us on the CNCF Slack ([get an invitation here][cncf-slack] )
* [#harbor][users-slack] for end-user discussions
* [#harbor-dev][dev-slack] for development of Harbor
* Want long-form communication instead of Slack? We have two distributions lists:
@ -47,7 +47,7 @@ To build the project, please refer the [build](https://goharbor.io/docs/edge/bui
### 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 key folders / files are commented for your references.
```
.
...
@ -200,7 +200,7 @@ To run the code, please refer to the [build](https://goharbor.io/docs/edge/build
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.
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.
Please submit a PR broken down into small changes bit by bit. A PR consisting of a lot of features and code changes may be hard to review. It is recommended to submit PRs in an incremental fashion.
Note: If you split your pull request to small changes, please make sure any of the changes goes to `main` will not break anything. Otherwise, it can not be merged until this feature complete.
@ -293,7 +293,7 @@ Please use `fetch / rebase` (as shown above) instead of `git pull`. `git pull` d
### Commit
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.
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
$ git commit -s -m 'This is my commit message'
@ -316,7 +316,7 @@ curl https://cdn.rawgit.com/tommarshall/git-good-commit/v0.6.1/hook.sh > .git/ho
### Automated Testing
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.
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.
* 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. Also, the source code will be checked via `gosec`, and the result is stored in google storage for later analysis. 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:

4
README.md
View File

@ -24,7 +24,7 @@ Please use [releases](https://github.com/vmware/harbor/releases) instead of the
Harbor is an open source trusted cloud native registry project that stores, signs, and scans content. Harbor extends the open source Docker Distribution by adding the functionalities usually required by users such as security, identity and management. Having a registry closer to the build and run environment can improve the image transfer efficiency. Harbor supports replication of images between registries, and also offers advanced security features such as user management, access control and activity auditing.
Harbor is hosted by the [Cloud Native Computing Foundation](https://cncf.io) (CNCF). If you are an organization that wants to help shape the evolution of cloud native technologies, consider joining the CNCF. For details about who's involved and how Harbor plays a role, read the CNCF
Harbor is hosted by the [Cloud Native Computing Foundation](https://cncf.io) (CNCF). If you are an organization that wants to help shape the evolution of cloud native technologies, consider joining the CNCF. For details about whose involved and how Harbor plays a role, read the CNCF
[announcement](https://www.cncf.io/blog/2018/07/31/cncf-to-host-harbor-in-the-sandbox/).
## Features
@ -96,7 +96,7 @@ For a list of users, please refer to [ADOPTERS.md](ADOPTERS.md).
### Security Audit
A third party security audit was performed by Cure53 in October of 2019. You can see the full report [here](https://goharbor.io/docs/2.0.0/security/Harbor_Security_Audit_Oct2019.pdf).
A third party security audit was performed by Cure53 in October 2019. You can see the full report [here](https://goharbor.io/docs/2.0.0/security/Harbor_Security_Audit_Oct2019.pdf).
### Reporting security vulnerabilities

8
RELEASES.md
View File

@ -1,5 +1,5 @@
# Versioning and Release
This document describes the versioning and release process of Harbor. This document is a living document, contents will be updated according to each releases.
This document describes the versioning and release process of Harbor. This document is a living document, contents will be updated according to each release.
## Releases
Harbor releases will be versioned using dotted triples, similar to [Semantic Version](http://semver.org/). For this specific document, we will refer to the respective components of this triple as `<major>.<minor>.<patch>`. The version number may have additional information, such as "-rc1,-rc2,-rc3" to mark release candidate builds for earlier access. Such releases will be considered as "pre-releases".
@ -29,12 +29,12 @@ The activity for next release will be tracked in the [up-to-date project board](
### Publishing a New Release
The following steps outline what to do when its time to plan for and publish a release. Depending on the release (major/minor/patch), not all the following items are needed.
The following steps outline what to do when it's time to plan for and publish a release. Depending on the release (major/minor/patch), not all the following items are needed.
1. Prepare information about what's new in the release.
* For every release, update documentation for changes that have happened in the release. See the [goharbor/website](https://github.com/goharbor/website) repo for more details on how to create documentation for a release. All documentation for a release should be published by the time the release is out.
* For every release, write release notes. See [previous releases](https://github.com/goharbor/harbor/releases) for examples of what to included in release notes.
* For a major/minor release, write a blog post that highlights new features in the release. Plan to publish this the same day as the release. Highlight the themes, or areas of focus, for the release. Some examples of themes are security, bug fixes, feature improvements. If there are any new features or workflows introduced in a release, consider writing additional blog posts to help users learn about the new features. Plan to publish these after the release date (all blogs don’t have to be publish all at once).
* For every release, write release notes. See [previous releases](https://github.com/goharbor/harbor/releases) for examples of what to include in release notes.
* For a major/minor release, write a blog post that highlights new features in the release. Plan to publish this the same day as the release. Highlight the themes, or areas of focus, for the release. Some examples of themes are security, bug fixes, feature improvements. If there are any new features or workflows introduced in a release, consider writing additional blog posts to help users learn about the new features. Plan to publish these after the release date (all blogs don’t have to be published all at once).
1. Release a new version. Make the new version, docs updates, and blog posts available.
1. Announce the release and thank contributors. We should be doing the following for all releases.
* In all messages to the community include a brief list of highlights and links to the new release blog, release notes, or download location. Also include shoutouts to community member contribution included in the release.

2
ROADMAP.md
View File

@ -2,7 +2,7 @@
### About this document
This document provides a link to the [Harbor Project board](https://github.com/orgs/goharbor/projects/1) that serves as the up to date description of items that are in the Harbor release pipeline. The board has separate swim lanes for each release. Most items are gathered from the community or include a feedback loop with the community. This should serve as a reference point for Harbor users and contributors to understand where the project is heading, and help determine if a contribution could be conflicting with a longer term plan.
This document provides a link to the [Harbor Project board](https://github.com/orgs/goharbor/projects/1) that serves as the up-to-date description of items that are in the Harbor release pipeline. The board has separate swim lanes for each release. Most items are gathered from the community or include a feedback loop with the community. This should serve as a reference point for Harbor users and contributors to understand where the project is heading, and help determine if a contribution could be conflicting with a longer term plan.
### How to help?

4
SECURITY.md
View File

@ -23,7 +23,7 @@ Provide a descriptive subject line and in the body of the email include the foll
## When to report a vulnerability
* When you think Harbor has a potential security vulnerability.
* When you suspect a potential vulnerability but you are unsure that it impacts Harbor.
* When you suspect a potential vulnerability, but you are unsure that it impacts Harbor.
* When you know of or suspect a potential vulnerability on another project that is used by Harbor. For example Harbor has a dependency on Docker, PGSql, Redis, Notary, Trivy, etc.
## Patch, Release, and Disclosure
@ -59,7 +59,7 @@ To be eligible to join the cncf-harbor-distributors-announce@lists.cncf.io maili
4. Not be a downstream or rebuild of another distributor.
5. Be a participant and active contributor in the Harbor community.
6. Accept the Embargo Policy that is outlined below.
7. Have someone who is already on the list vouch for the person requesting membership on behalf of your distribution.
7. Has someone who is already on the list vouch for the person requesting membership on behalf of your distribution.
**The terms and conditions of the Embargo Policy apply to all members of this mailing list. A request for membership represents your acceptance to the terms and conditions of the Embargo Policy**