mirror of https://github.com/goharbor/harbor.git
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>
This commit is contained in:
Josh Soref
Ziming
parent
74b6bfe731
commit
dfe360040b
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
6
Makefile
6
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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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 / {
|
||||
|
|
|
|||
|
|
@ -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 / {
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@
|
|||
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)}}
|
||||
|
|
|
|||
|
|
@ -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;
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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**
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ In below test, user A is non-admin user. User A should be replaced by a longer a
|
|||
4. Search projects with keywords to see if the list and pagination update accordingly.
|
||||
|
||||
# Expected Outcome:
|
||||
* As descirbed in step 3-4.
|
||||
* As described in step 3-4.
|
||||
|
||||
# Possible Problems:
|
||||
None
|
||||
|
|
@ -36,7 +36,7 @@ User guide
|
|||
13. In user A's UI, recreate project X,
|
||||
14. On a Docker client, log in as User A and run `docker push` to push an image to project X, e.g. projectX/anotherimage:v1. The image name should not be the same as those deleted in previous steps.
|
||||
15. Switch to the UI of admin user, view images under the re-created project X.
|
||||
16. As an admin user, view the log in dashboard and should see delete and create operaions of project X.
|
||||
16. As an admin user, view the log in dashboard and should see delete and create operations of project X.
|
||||
|
||||
# Expected Outcome:
|
||||
* Step 6, deleting project X should fail because there are images under it.
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ In below test, user A is non-admin user. User A should be replaced by a longer a
|
|||
6. Check in "Public Projects" to verify the projects with publicity on can be listed.
|
||||
|
||||
# Expected Outcome:
|
||||
* As descirbed in step 4,6.
|
||||
* As described in step 4,6.
|
||||
|
||||
# Possible Problems:
|
||||
None
|
||||
|
|
@ -30,7 +30,7 @@ User guide
|
|||
7. Delete project X. (should fail with errors)
|
||||
8. Delete all images of project X.
|
||||
9. Delete project X.
|
||||
10. As an admin user, view the log in dashboard and should see delete operaion of project X and its images.
|
||||
10. As an admin user, view the log in dashboard and should see delete operation of project X and its images.
|
||||
|
||||
# Expected Outcome:
|
||||
* Step 7, deleting project X should fail because there are images under it.
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ User guide
|
|||
1. Create group harbor_guest, harbor_dev, harbor_admin in LDAP.
|
||||
1. Create LDAP user guest_user, dev_user, admin_user in LDAP.
|
||||
Assign add group following members
|
||||
* harbbor_guest --- guest_user, admin_user.
|
||||
* harbor_guest --- guest_user, admin_user.
|
||||
* harbor_dev --- dev_user.
|
||||
* harbor_admin --- admin_user.
|
||||
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ User guide, Installation guide of Harbor OVA version.
|
|||
# Test Steps:
|
||||
|
||||
To-Do:
|
||||
1. verify all setttings work at initial import
|
||||
1. verify all settings work at initial import
|
||||
2. verify all settings work after a hard power off followed by a power on
|
||||
3. Verify all settings can be changed as needed. (except networks, root password, Harbor password , mysql password)
|
||||
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ User guide
|
|||
3. Choose a project by clicking the icon on the right of `Projects`.
|
||||
4. Add repository and tag filter.
|
||||
5. Choose an endpoint, create a new one if no endpoint exists.
|
||||
6. Select a triggering condition: Immediate/Manaul/Scheduled, check/uncheck the `Delete remote images when locally deleted` if choosing `Immediate`.
|
||||
6. Select a triggering condition: Immediate/Manual/Scheduled, check/uncheck the `Delete remote images when locally deleted` if choosing `Immediate`.
|
||||
7. Check/uncheck the option `Replicate existing images immediately`.
|
||||
8. Save the rule.
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ Test 7-02 - Edit replication rules
|
|||
|
||||
# Purpose:
|
||||
|
||||
To verify admin user can edit repliciation rules.
|
||||
To verify admin user can edit replication rules.
|
||||
|
||||
# References:
|
||||
User guide
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ To verify rule filter works correctly.
|
|||
User guide
|
||||
|
||||
# Environment:
|
||||
* This test requires that two Harbor instance are running and avaiable.
|
||||
* This test requires that two Harbor instance are running and available.
|
||||
|
||||
# Test Steps:
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ Test 7-13 Endpoints endpoints edit
|
|||
|
||||
# Purpose
|
||||
|
||||
To verify admin user can edit edpoints.
|
||||
To verify admin user can edit endpoints.
|
||||
|
||||
# References:
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ User guide
|
|||
|
||||
# Environment:
|
||||
|
||||
* This test requires one Harbor instance is runnning and available.
|
||||
* This test requires one Harbor instance is running and available.
|
||||
* A Linux host with Docker CLI installed (Docker client).
|
||||
|
||||
# Test Steps:
|
||||
|
|
@ -18,10 +18,10 @@ User guide
|
|||
In below test, <harbor_ip> should be replaced by your harbor's ip or FQDN. If you are using a self-signed certificate,make sure to copy the CA root cert into ```/etc/docker/certs.d/<harbor_ip>``` and ```$HOME/.docker/tls/<harbor_ip>:4443/```
|
||||
|
||||
1. Login UI and create a project.
|
||||
2. On Docker clinet, run
|
||||
2. On Docker client, run
|
||||
```sh
|
||||
export DOCKER_CONTENT_TRUST=1
|
||||
export DOCKER_CONTNET_TRUST_SERVER=https://<harbor_ip>:4443
|
||||
export DOCKER_CONTENT_TRUST_SERVER=https://<harbor_ip>:4443
|
||||
```
|
||||
and login Harbor.
|
||||
3. Push an image to the project created in step1.
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ User guide
|
|||
|
||||
# Environment:
|
||||
|
||||
* This test requires one Harbor instance is runnning and available.
|
||||
* This test requires one Harbor instance is running and available.
|
||||
* A Linux host with Docker CLI (Docker client) installed.
|
||||
|
||||
# Test Steps:
|
||||
|
|
@ -21,7 +21,7 @@ User guide
|
|||
|
||||
# Expected Outcome:
|
||||
|
||||
* A red cross will displayed under signed colume in UI.
|
||||
* A red cross will displayed under signed column in UI.
|
||||
|
||||
# Possible Problems:
|
||||
None
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ In below test, project X should be replaced by an existing project and <harbor_i
|
|||
export DOCKER_CONTENT_TRUST=1
|
||||
export DOCKER_CONTENT_TRUST_SERVER=https://<harbor_ip>:4443
|
||||
```
|
||||
and login Harobr.
|
||||
and login Harbor.
|
||||
3. Pull an image from project X.
|
||||
|
||||
# Expected Outcome:
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ User guide
|
|||
|
||||
# Environment:
|
||||
|
||||
* This test requires one Harbor instance is running and avialable.
|
||||
* This test requires one Harbor instance is running and available.
|
||||
* A Linux host with Docker CLI(Docker client) installed.
|
||||
|
||||
# Test Steps:
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ Test 9-12 User push unsigned images(LDAP mode)
|
|||
|
||||
# Purpose:
|
||||
|
||||
To verify UI will difference unsiged images from signed.
|
||||
To verify UI will difference unsigned images from signed.
|
||||
|
||||
# References:
|
||||
User guide
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ User guide
|
|||
* This test requires that a Harbor instance is running and available.
|
||||
* Harbor is set to authenticate against an LDAP or AD server.
|
||||
* A Linux host with Docker CLI(Docker client)installed.
|
||||
* A non-admin user that has at least one proejct as project admin.
|
||||
* A non-admin user that has at least one project as project admin.
|
||||
|
||||
# Test Steps:
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ User guide
|
|||
|
||||
# Environment:
|
||||
|
||||
* This test requries a Harbor istance is running and available.
|
||||
* This test requires a Harbor instance is running and available.
|
||||
* Harbor is set authenticate against an LDAP or AD server.
|
||||
* A Linux host with Docker CLI(Docker client)installed.
|
||||
* A non-admin user that has at least one project as project admin.
|
||||
|
|
|
|||
|
|
@ -10,20 +10,20 @@ User guide
|
|||
|
||||
# Environment:
|
||||
|
||||
* This test requires one Harbor instance is runnning and available.
|
||||
* This test requires one Harbor instance is running and available.
|
||||
* A Linux host with Docker CLI installed (Docker client).
|
||||
|
||||
# Test Steps:
|
||||
**NOTE:**
|
||||
In below test, <harbor_ip> should be replaced by your harbor's ip or FQDN. If you are using a self-signed certificate,make sure to copy the CA root cert into ```/etc/docker/certs.d/<harbor_ip>``` and ```$HOME/.docker/tls/<harbor_ip>:4443/```
|
||||
project a should be replaced by meaingful and longer name.
|
||||
project a should be replaced by meaningful and longer name.
|
||||
|
||||
1. Login UI and create a project a.
|
||||
2. Push an image to project a.
|
||||
3. On Docker clinet, run
|
||||
3. On Docker client, run
|
||||
```sh
|
||||
export DOCKER_CONTENT_TRUST=1
|
||||
export DOCKER_CONTNET_TRUST_SERVER=https://<harbor_ip>:4443
|
||||
export DOCKER_CONTENT_TRUST_SERVER=https://<harbor_ip>:4443
|
||||
```
|
||||
and login Harbor.
|
||||
4. Push an image to project a.
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ Harbor supports two different ways to storage the chart data.
|
|||
1. stored in Harbor registry storage directly via OCI API.
|
||||
2. stored in Harbor hosted chartmuseum backend via chartmuseam's API
|
||||
|
||||
There is an performance issue in chartmuseam. For example, on my 2 core 8G memory test environment, to get 10000 charts infomation needs about 10s to return, In 50000 charts situation, It will cause a timeout error.
|
||||
There is an performance issue in chartmuseam. For example, on my 2 core 8G memory test environment, to get 10000 charts information needs about 10s to return, In 50000 charts situation, It will cause a timeout error.
|
||||
|
||||
After version 2.0, Harbor becomes to the OCI registry. So It can storage chart content directly without chartmuseum.
|
||||
|
||||
|
|
|
|||
|
|
@ -189,7 +189,7 @@ type SwaggerPetstore {
|
|||
}
|
||||
```
|
||||
|
||||
Thos fields are objects, which implements interfaces declared in the [pet](./example/client/pet) and
|
||||
Those fields are objects, which implements interfaces declared in the [pet](./example/client/pet) and
|
||||
[store](./example/client/store) packages:
|
||||
|
||||
For example:
|
||||
|
|
@ -242,7 +242,7 @@ Here we defined an apiKey, that is passed through the Cookie header.
|
|||
|
||||
The `security` section defines the default security enforcement for the application. You can select
|
||||
different securityDefinitions, as the keys, and apply "scopes" as the values. Those default definitions
|
||||
can be overriden in each route by a section with the same name:
|
||||
can be overridden in each route by a section with the same name:
|
||||
|
||||
```yaml
|
||||
paths:
|
||||
|
|
@ -253,7 +253,7 @@ paths:
|
|||
- token: [admin]
|
||||
```
|
||||
|
||||
Here we overriden the scope of token in the POST /pets URL so that only admin can use this API.
|
||||
Here we overridden the scope of token in the POST /pets URL so that only admin can use this API.
|
||||
|
||||
Let's see how we can use this functionality.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue