Spelling

* addition * attribute * auditing * availability * available * bandwidth * browser * business * cadence * chartmuseum * client * column * content * demonstrate * described * endpoints * facilitate * github * harbor * information * instance * manual * meaningful * operation * overridden * password * possible * project * refactor * replication * requires * running * scanned * settings * signup * those * unsigned * vulnerability -- Also removes trailing space from a filename Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>
goharbor · Feb 19, 2021 · dfe3600 · dfe3600
1 parent 74b6bfe
commit dfe3600
Show file tree

Hide file tree

Showing 46 changed files with 67 additions and 67 deletions.
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -17,7 +17,7 @@ API explorer integration. End users can now explore and trigger Harbor’s API v
 * Bumped up Clair to v2.0.8
 * Fixed issues in supporting windows images. #6992 #6369
 * Removed user-agent check-in notification handler. #5729
-* Fixed the issue global search not working if chartmusuem is not installed #6753
+* Fixed the issue global search not working if chartmuseum is not installed #6753
 
 ## v1.7.4 (2019-03-04)
 [Full list of issues fixed in v1.7.4](https://github.com/goharbor/harbor/issues?q=is%3Aissue+is%3Aclosed+label%3Atarget%2F1.7.4)
@@ -84,7 +84,7 @@ API explorer integration. End users can now explore and trigger Harbor’s API v
 
 ## v0.5.0 (2016-12-6)
 
-- Refactory for a new build process
+- Refactor for a new build process
 - Easier configuration for HTTPS in prepare script
 - Script to collect logs of a Harbor deployment
 - User can view the storage usage (default location) of Harbor.
@@ -100,7 +100,7 @@ For Harbor virtual appliance:
 ## v0.4.5 (2016-10-31)
 
 - Virtual appliance of Harbor for vSphere.
-- Refactory for new build process.
+- Refactor for new build process.
 - Easier configuration for HTTPS in prepare step.
 - Updated documents.
 - Various bug fixes.
@@ -149,6 +149,6 @@ Initial release, key features include
 - Role based access control (RBAC)
 - LDAP / AD integration
 - Graphical user interface (GUI)
-- Auditting and logging
+- Auditing and logging
 - RESTful API
 - Internationalization
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -91,7 +91,7 @@ The folder graph below shows the structure of the source code folder `harbor/src
 │   ├── scanner
 │   ├── tag
 │   ├── task
-├── core                # Source code for the main busines logic. Contains rest apis and all service infomation.
+├── core                # Source code for the main business logic. Contains rest apis and all service information.
 │   ├── api
 │   ├── auth
 │   ├── config
@@ -336,7 +336,7 @@ Commit changes made in response to review comments to the same branch on your fo
 
 ## Reporting issues
 
-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.
+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.
 
 Before opening any issue, please look up the existing [issues](https://github.com/goharbor/harbor/issues) to avoid submitting a duplication.
 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.

diff --git a/Makefile b/Makefile
@@ -14,7 +14,7 @@
 #
 # build:	build Harbor docker images from photon baseimage
 #
-# install:		include compile binarys, build images, prepare specific \
+# install:		include compile binaries, build images, prepare specific \
 #				version composefile and startup Harbor instance
 #
 # start:		startup Harbor instance
@@ -54,10 +54,10 @@
 # cleanpackage: remove online/offline install package
 #
 # other example:
-#	clean specific version binarys and images:
+#	clean specific version binaries and images:
 #				make clean -e VERSIONTAG=[TAG]
 #				note**: If commit new code to github, the git commit TAG will \
-#				change. Better use this commond clean previous images and \
+#				change. Better use this command clean previous images and \
 #				files with specific TAG.
 #   By default DEVFLAG=true, if you want to release new version of Harbor, \
 #		should setting the flag to false.

diff --git a/README.md b/README.md
@@ -30,12 +30,12 @@ Harbor is hosted by the [Cloud Native Computing Foundation](https://cncf.io) (CN
 
 * **Cloud native registry**: With support for both container images and [Helm](https://helm.sh) charts, Harbor serves as registry for cloud native environments like container runtimes and orchestration platforms.
 * **Role based access control**: Users access different repositories through 'projects' and a user can have different permission for images or Helm charts under a project.
-* **Policy based replication**: Images and charts can be replicated (synchronized) between multiple registry instances based on policies with using filters (repository, tag and label). Harbor automatically retries a replication if it encounters any errors. This can be used to assist loadbalancing, achieve high availabiliy, and faciliate multi-datacenter deployments in hybrid and multi-cloud scenarios.
+* **Policy based replication**: Images and charts can be replicated (synchronized) between multiple registry instances based on policies with using filters (repository, tag and label). Harbor automatically retries a replication if it encounters any errors. This can be used to assist loadbalancing, achieve high availability, and facilitate multi-datacenter deployments in hybrid and multi-cloud scenarios.
 * **Vulnerability Scanning**: Harbor scans images regularly for vulnerabilities and has policy checks to prevent vulnerable images from being deployed.
 * **LDAP/AD support**: Harbor integrates with existing enterprise LDAP/AD for user authentication and management, and supports importing LDAP groups into Harbor that can then be given permissions to specific projects.  
 * **OIDC support**: Harbor leverages OpenID Connect (OIDC) to verify the identity of users authenticated by an external authorization server or identity provider. Single sign-on can be enabled to log into the Harbor portal.  
 * **Image deletion & garbage collection**: System admin can run garbage collection jobs so that images(dangling manifests and unreferenced blobs) can be deleted and their space can be freed up periodically.
-* **Notary**: Support signing container images using Docker Content Trust (leveraging Notary) for guaranteeing authenticity and provenance.  In additon, policies that prevent unsigned images from being deployed can also be activated.
+* **Notary**: Support signing container images using Docker Content Trust (leveraging Notary) for guaranteeing authenticity and provenance.  In addition, policies that prevent unsigned images from being deployed can also be activated.
 * **Graphical user portal**: User can easily browse, search repositories and manage projects.
 * **Auditing**: All the operations to the repositories are tracked through logs.
 * **RESTful API**: RESTful APIs are provided to facilitate administrative operations, and are easy to use for integration with external systems. An embedded Swagger UI is available for exploring and testing the API.

diff --git a/RELEASES.md b/RELEASES.md
@@ -5,10 +5,10 @@ This document describes the versioning and release process of Harbor. This docum
 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".
 
 ### Major and Minor Releases
-Major and minor releases of Harbor will be branched from master when the release reaches to `RC(release candidate)` state. The branch format should follow `release-<major>.<minor>.0`. For example, once the release `v1.0.0` reaches to RC, a branch will be created with the format `release-1.0.0`. When the release reaches to `GA(General Available)` state, The tag with format `v<major>.<minor>.<patch>` and should be made with command `git tag -s v<major>.<minor>.<patch>`. The release cadency is around 3 months, might be adjusted based on open source event, but will communicate it clearly.
+Major and minor releases of Harbor will be branched from master when the release reaches to `RC(release candidate)` state. The branch format should follow `release-<major>.<minor>.0`. For example, once the release `v1.0.0` reaches to RC, a branch will be created with the format `release-1.0.0`. When the release reaches to `GA(General Available)` state, The tag with format `v<major>.<minor>.<patch>` and should be made with command `git tag -s v<major>.<minor>.<patch>`. The release cadence is around 3 months, might be adjusted based on open source event, but will communicate it clearly.
 
 ### Patch releases
-Patch releases are based on the major/minor release branch, the release cadency for patch release of recent minor release is one month to solve critical community and security issues. The cadency for patch release of recent minus two minor releases are on-demand driven based on the severity of the issue to be fixed.
+Patch releases are based on the major/minor release branch, the release cadence for patch release of recent minor release is one month to solve critical community and security issues. The cadence for patch release of recent minus two minor releases are on-demand driven based on the severity of the issue to be fixed.
 
 ### Pre-releases
 `Pre-releases:mainly the different RC builds` will be compiled from their corresponding branches. Please note they are done to assist in the stabilization process, no guarantees are provided.

diff --git a/contrib/registryapi/README.md b/contrib/registryapi/README.md
@@ -18,7 +18,7 @@ res = api.deleteManifest('public/ubuntu', '23424545**4343')
 operations for repo, tag, manifest
 ```
 usage:
-./cli.py --username username --password passwrod --registry_endpoint http://www.your_registry_url.com/ target action params
+./cli.py --username username --password password --registry_endpoint http://www.your_registry_url.com/ target action params
 
 target can be: repo, tag, manifest
 action can be: list, get, delete

diff --git a/make/photon/prepare/templates/nginx/nginx.http.conf.jinja b/make/photon/prepare/templates/nginx/nginx.http.conf.jinja
@@ -51,7 +51,7 @@ http {
     add_header X-Frame-Options DENY;
     add_header Content-Security-Policy "frame-ancestors 'none'";
 
-    # costumized location config file can place to /etc/nginx/etc with prefix harbor.http. and suffix .conf
+    # customized location config file can place to /etc/nginx/etc with prefix harbor.http. and suffix .conf
     include /etc/nginx/conf.d/harbor.http.*.conf;
 
     location / {

diff --git a/make/photon/prepare/templates/nginx/nginx.https.conf.jinja b/make/photon/prepare/templates/nginx/nginx.https.conf.jinja
@@ -69,7 +69,7 @@ http {
     add_header X-Frame-Options DENY;
     add_header Content-Security-Policy "frame-ancestors 'none'";
 
-    # costumized location config file can place to /etc/nginx dir with prefix harbor.https. and suffix .conf
+    # customized location config file can place to /etc/nginx dir with prefix harbor.https. and suffix .conf
     include /etc/nginx/conf.d/harbor.https.*.conf;
 
     location / {

diff --git a/make/photon/redis/redis.conf b/make/photon/redis/redis.conf
@@ -202,7 +202,7 @@ always-show-logo yes
 #   Will save the DB if both the given number of seconds and the given
 #   number of write operations against the DB occurred.
 #
-#   In the example below the behaviour will be to save:
+#   In the example below the behavior will be to save:
 #   after 900 sec (15 min) if at least 1 key changed
 #   after 300 sec (5 min) if at least 10 keys changed
 #   after 60 sec if at least 10000 keys changed
@@ -637,7 +637,7 @@ slave-priority 100
 #    it with the specified string.
 # 4) During replication, when a slave performs a full resynchronization with
 #    its master, the content of the whole database is removed in order to
-#    load the RDB file just transfered.
+#    load the RDB file just transferred.
 #
 # In all the above cases the default is to delete objects in a blocking way,
 # like if DEL was called. However you can configure each case specifically

diff --git a/src/jobservice/README.md b/src/jobservice/README.md
@@ -172,7 +172,7 @@ ctx.Checkin("30%")
 Here is a demo job:
 
 ```go
-// DemoJob is the job to demostrate the job interface.
+// DemoJob is the job to demonstrate the job interface.
 type DemoJob struct{}
 
 // MaxFails is implementation of same method in Interface.

diff --git a/...-nav/project-quotas/project-quotas/edit-project-quotas/edit-project-quotas.component.html b/...-nav/project-quotas/project-quotas/edit-project-quotas/edit-project-quotas.component.html
@@ -31,7 +31,7 @@ <h3 class="modal-title">{{ defaultTextsObj.editQuota }}</h3>
                       data-displayval="100%"></progress>
                   </div>
                   <label class="progress-label">
-                    <!-- the comments of progress , when storageLimit !=-1  get integet and unit  in hard storage and used storage;and the unit of used storage <= the unit of hard storage 
+                    <!-- the comments of progress , when storageLimit !=-1  get integer and unit  in hard storage and used storage;and the unit of used storage <= the unit of hard storage 
                     the other : get suitable number and unit-->
                     {{ +quotaHardLimitValue.storageLimit !== -1 ?(getIntegerAndUnit(getByte(quotaHardLimitValue.storageLimit,quotaHardLimitValue.storageUnit), quotaHardLimitValue.storageUsed).partNumberUsed
                       + getIntegerAndUnit(getByte(quotaHardLimitValue.storageLimit,quotaHardLimitValue.storageUnit), quotaHardLimitValue.storageUsed).partCharacterUsed) : getSuitableUnit(quotaHardLimitValue.storageUsed)}}

diff --git a/src/portal/src/app/shared/components/global-search/search.component.scss b/src/portal/src/app/shared/components/global-search/search.component.scss
@@ -3,7 +3,7 @@
     position: fixed;
     height: 100%;
     width: 100%;
-    /*shoud be lesser than 1000 to aoivd override the popup menu*/
+    /*should be lesser than 1000 to avoid override the popup menu*/
     z-index: 999;
     box-sizing: border-box;
     background: #fafafa;

diff --git a/tests/testcases/Group1-user-management/1-01-DB-user-registration.md b/tests/testcases/Group1-user-management/1-01-DB-user-registration.md
@@ -3,7 +3,7 @@ Test 1-01 - User Registration (DB Mode)
 
 # Purpose:
 
-To verify that a non-admin user can register an account (singup) when users are managed locally by Harbor (DB mode).
+To verify that a non-admin user can register an account (signup) when users are managed locally by Harbor (DB mode).
 
 # References:
 User guide

diff --git a/tests/testcases/Group1-user-management/1-05-LDAP-user-log-in-log-out.md b/tests/testcases/Group1-user-management/1-05-LDAP-user-log-in-log-out.md
@@ -16,7 +16,7 @@ User guide
 
 # Test Steps:
 
-1. A user has **NEVER** logged in to Harbor. He/she logs in to the UI for the first time by his/her id in LDAP. The id could be the uid attribte (or what is configured in ldap_uid) of his/her LDAP user DN.
+1. A user has **NEVER** logged in to Harbor. He/she logs in to the UI for the first time by his/her id in LDAP. The id could be the uid attribute (or what is configured in ldap_uid) of his/her LDAP user DN.
 2. The user logs out from the UI.
 3. The user logs in again to the UI, should not see his/her own account settings and cannot change password(need to go to LDAP/AD for this).
 4. The user logs out from the UI.

diff --git a/tests/testcases/Group1-user-management/1-06-AD-user-log-in-log-out.md b/tests/testcases/Group1-user-management/1-06-AD-user-log-in-log-out.md
@@ -16,7 +16,7 @@ User guide
 
 # Test Steps:
 
-1. A user has **NEVER** logged in to Harbor. He/she logs in to the UI for the first time by his/her id in AD. The id could be the cn attribte (or what is configured in ldap_uid) of his/her AD user DN.
+1. A user has **NEVER** logged in to Harbor. He/she logs in to the UI for the first time by his/her id in AD. The id could be the cn attribute (or what is configured in ldap_uid) of his/her AD user DN.
 2. The user logs out from the UI.
 3. The user logs in again to the UI, should not see his/her own account settings and cannot change password(need to go to LDAP/AD for this).
 4. The user logs out from the UI.

diff --git a/tests/testcases/Group1-user-management/1-09-admin-create-delete-user.md b/tests/testcases/Group1-user-management/1-09-admin-create-delete-user.md
@@ -22,7 +22,7 @@ User guide
 5. The user create two projects in the UI.
 6. On a Docker client host, use `docker login <harbor_host>` command to verify the user can log in.
 7. The admin user deletes the user from the UI.
-8. When clicking on any link on the page, the deleted user's session on the different browswer should be redirected to the login page and logged out.  
+8. When clicking on any link on the page, the deleted user's session on the different browser should be redirected to the login page and logged out.  
 9. On a Docker client host, use `docker login <harbor_host>` command to verify the user cannot log in.
 10. The admin user re-creates a user with the same username of the deleted user.
 11. On a different browser, log in as the re-created user.

diff --git a/tests/testcases/Group10-Vulnerability/10-04-Clair-data-not-ready-hint.md b/tests/testcases/Group10-Vulnerability/10-04-Clair-data-not-ready-hint.md
@@ -11,7 +11,7 @@ User guide
 * This test requires that a Harbor instance is running and available.  
 * Harbor is installed with trivy enable.  
 * A linux host with Docker CLI installed.  
-* Limit the Harbor's bandwith to less than 1Mbps after Harbor is installed.  
+* Limit the Harbor's bandwidth to less than 1Mbps after Harbor is installed.  
 
 # Test Step:  
 **NOTE:This test need to be done as soon as possible after Harbor is installed**  

diff --git a/tests/testcases/Group10-Vulnerability/10-05-Schedule-daily-scan.md b/tests/testcases/Group10-Vulnerability/10-05-Schedule-daily-scan.md
@@ -27,5 +27,5 @@ User guide
 * Step6 the timestamp should be the same as scheduled.  
 * Step9 the timestamp should be the same as scheduled.  
 
-# Posssible Problems:  
+# Possible Problems:  
 None  
diff --git a/tests/testcases/Group10-Vulnerability/10-06-Change-scan-configuration.md b/tests/testcases/Group10-Vulnerability/10-06-Change-scan-configuration.md
@@ -17,7 +17,7 @@ User guide
 1. Login harbor as admin.   
 2. Push a image to a project.   
 3. Click configuration.   
-4. Click vunlerablity.   
+4. Click vulnerability.   
 5. Set scan all to none.   
 6. Click scan now.   
 7. Check scan now button.  

diff --git a/...rability/10-08-User-can-not-pull-image-exceed-vulnerability-severity-setting.md b/...rability/10-08-User-can-not-pull-image-exceed-vulnerability-severity-setting.md
@@ -7,7 +7,7 @@ To verify user can not pull image exceed vulnerability severity setting.
 User guide.  
 
 # Environment:
-* This test requires that one Harbor instance is running and availiable.  
+* This test requires that one Harbor instance is running and available.  
 * Harbor is installed with trivy enable.  
 * A Linux host with Docker client installed.  
 * Trivy has been updated to the latest.  
@@ -17,7 +17,7 @@ User guide.
 2. Go to configuration.  
 3. Set vulnerability severity limit to medium and save configuration.  
 4. Push some images with vulnerability and scan them.  
-5. On a docker client, user pull an image with high vulneability severity. 
+5. On a docker client, user pull an image with high vulnerability severity. 
 
 # Expect outcome:
 * Step5 pull request should be refused.  

diff --git a/tests/testcases/Group10-Vulnerability/10-09-User-can-pull-scaned-images.md b/tests/testcases/Group10-Vulnerability/10-09-User-can-pull-scaned-images.md
@@ -1,13 +1,13 @@
 10-09  
 =======
 # Purpose:
-To test normal user can pull scaned images.  
+To test normal user can pull scanned images.  
 
 # Reference:
 User guide.  
 
 # Environment:
-* This test requires that one Harbor instance is running and availiable.  
+* This test requires that one Harbor instance is running and available.  
 * Harbor is installed with trivy enable.  
 * A Linux host with Docker client installed.  
 * Trivy has been updated to the latest.  
@@ -20,7 +20,7 @@ In below test, user A is a non-admin user. User A should be replaced by meaningf
 1. Login as user A. 
 2. Create a project and push an image. 
 3. Login as admin and scan the image.  
-4. On a Docker client, user A pull the scaned image.  
+4. On a Docker client, user A pull the scanned image.  
 
 # Expect Outcome:
 * Step 4 user can pull the image.  

diff --git a/tests/testcases/Group10-Vulnerability/10-10-Manual-scan-all.md b/tests/testcases/Group10-Vulnerability/10-10-Manual-scan-all.md
@@ -7,7 +7,7 @@ To verify scan all button works correctly.
 User guide.  
 
 # Environment:
-* This test requires that one Harbor instance is running and availiable.  
+* This test requires that one Harbor instance is running and available.  
 * Harbor is installed with trivy enable.  
 * A Linux host with Docker client installed.  
 * Trivy has been updated to the latest.  

diff --git a/tests/testcases/Group10-Vulnerability/10-11-User-fix-vulnerability.md b/tests/testcases/Group10-Vulnerability/10-11-User-fix-vulnerability.md
@@ -1,13 +1,13 @@
 10-07  user fix vulnerability
 =======
 # Purpose:
-To test trivy scan image vulnerablity correct after user fix it.  
+To test trivy scan image vulnerability correct after user fix it.  
 
 # Reference:
 User guide.  
 
 # Environment:
-* This test requires that one Harbor instance is running and availiable.  
+* This test requires that one Harbor instance is running and available.  
 * Harbor is installed with trivy enable.  
 * A Linux host with Docker client installed.  
 * Trivy has been updated to the latest.  
@@ -16,7 +16,7 @@ User guide.
 1. Login Harbor as admin.  
 2. Push some images with vulnerability.  
 3. Scan an image with vulnerability and record the result.  
-4. Upgrade the image to fix vulnearbility.  
+4. Upgrade the image to fix vulnerability.  
 5. Rescan the same image and check the result.  
 
 # Expect Outcome:

diff --git a/tests/testcases/Group10-Vulnerability/Test-10-12-Scan-image-on-push.md b/tests/testcases/Group10-Vulnerability/Test-10-12-Scan-image-on-push.md
@@ -21,5 +21,5 @@ User guide
 5. Push an image not scanned before to the project.  
 
 # Expected Outcome:    
-* Step5 image should be scaned automatically.  
+* Step5 image should be scanned automatically.  
 
diff --git a/tests/testcases/Group2-image-management/2-01-DB-user-create-project.md b/tests/testcases/Group2-image-management/2-01-DB-user-create-project.md
@@ -22,7 +22,7 @@ In below test, user A and B are non-admin users. User A, B and project X, Y shou
 1. Log in to UI as user A (non-admin).
 2. Create a new project X with publicity is off (default).
 3. Create another new project Y with publicity is on .
-4. While keeping user A logging on, in another browswer log in as user B (non-admin).
+4. While keeping user A logging on, in another browser log in as user B (non-admin).
 5. User B checks his/her public projects to see if project Y is listed and project X is not listed.
 6. User A changes project X's publicity to on, project Y's publicity to off.
 7. User B refreshes his/her public projects to see if project X is listed and project Y is not listed.