mirror of https://github.com/goharbor/harbor.git
xaleeks
parent
5289b3519e
commit
e6fa7e1545
Binary file not shown.
|
After Width: | Height: | Size: 19 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 47 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 13 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 9.1 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 44 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 6.9 KiB |
|
|
@ -0,0 +1,13 @@
|
|||
---
|
||||
title: Tagging Artifacts
|
||||
weight: 75
|
||||
---
|
||||
|
||||
Harbor v2.0 now supports OCI images and OCI image indexes (https://github.com/opencontainers/image-spec/blob/master/image-index.md). An OCI image index (or OCI index) is a higher level manifest which points to a list of image manifests, ideal for one or more platforms. Both the index itself and the images referenced within are referred to as artifacts in Harbor parlance. An OCI index could hold another OCI index and so on and so forth. For any artifact referenced by an OCI index, the referenced artifact is known as the child artifact and the OCI index referencing the artifact is known as the parent artifact. We can also say that the child artifact belongs to the parent artifact or is a part of the parent artifact.
|
||||
|
||||
Users can add as many tags to any artifact as they wish without impacting the artifact digest or the associated storage. For an OCI index, users can add tags to the parent as well as add tags to the individual referenced artifacts within. Tags added to the parent artifact are not automatically inherited by the children artifacts. You can tag artifacts on the Harbor web console as follows:
|
||||
|
||||
In the Harbor interface, click on an artifact to see its current set of tags, then click 'ADD TAG', specify the name and click 'OK'
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,50 @@
|
|||
---
|
||||
title: Deleting Artifacts
|
||||
weight: 75
|
||||
---
|
||||
|
||||
Harbor v2.0 now supports OCI images and OCI image indexes (https://github.com/opencontainers/image-spec/blob/master/image-index.md). An OCI image index (or OCI index) is a higher level manifest which points to a list of image manifests, ideal for one or more platforms. Both the index itself and the images referenced within are referred to as artifacts in Harbor parlance. An OCI index could hold another OCI index and so on and so forth. For any artifact referenced by an OCI index, the referenced artifact is known as the child artifact and the OCI index referencing the artifact is known as the parent artifact. We can also say that the child artifact belongs to the parent artifact or is a part of the parent artifact.
|
||||
|
||||
An example of an OCI image index
|
||||
|
||||
```
|
||||
{
|
||||
"schemaVersion": 2,
|
||||
"manifests": [
|
||||
{
|
||||
"mediaType": "application/vnd.oci.image.manifest.v1+json",
|
||||
"size": 7143,
|
||||
"digest": "sha256:e692418e4cbaf90ca69d05a66403747baa33ee08806650b51fab815ad7fc331f",
|
||||
"platform": {
|
||||
"architecture": "ppc64le",
|
||||
"os": "linux"
|
||||
}
|
||||
},
|
||||
{
|
||||
"mediaType": "application/vnd.oci.image.manifest.v1+json",
|
||||
"size": 7682,
|
||||
"digest": "sha256:5b0bcabd1ed22e9fb1310cf6c2dec7cdef19f0ad69efa1f392e94a4333501270",
|
||||
"platform": {
|
||||
"architecture": "amd64",
|
||||
"os": "linux"
|
||||
}
|
||||
}
|
||||
],
|
||||
"annotations": {
|
||||
"com.example.key1": "value1",
|
||||
"com.example.key2": "value2"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Deleting Artifact**:
|
||||
|
||||
When an artifact is not referenced by any OCI index, you can delete the artifact freely which will delete its manifest and all associated tags.
|
||||
|
||||
When an artifact is referenced by an OCI index, you cannot delete it. In order to delete this artifact, you must first delete all OCI indexes referencing this artifact first, remembering that an artifact can be referenced by multiple parents artifacts pushed onto Harbor by different users. So when deleting an OCI index holding 9 children artifacts not referenced by any other index and 1 child artifact referenced by another index, only 9 out of 10 children artifacts will be deleted.
|
||||
|
||||
To delete any artifact in the Harbor interface, click on the artifact and select 'Delete' and confirm.
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
---
|
||||
title: Detagging Artifacts
|
||||
weight: 75
|
||||
---
|
||||
|
||||
Harbor v2.0 now supports OCI images and OCI image indexes (https://github.com/opencontainers/image-spec/blob/master/image-index.md). An OCI image index (or OCI index) is a higher level manifest which points to a list of image manifests, ideal for one or more platforms. Both the index itself and the images referenced within are referred to as artifacts in Harbor parlance. An OCI index could hold another OCI index and so on and so forth. For any artifact referenced by an OCI index, the referenced artifact is known as the child artifact and the OCI index referencing the artifact is known as the parent artifact. We can also say that the child artifact belongs to the parent artifact or is a part of the parent artifact.
|
||||
|
||||
Users can delete any existing tag from an artifact without deleting the artifact digest and all other existing tags. For an OCI index, users can delete tags from the parent as well as from the referenced artifacts within. Tags removed from the parent artifact are not automatically removed from children artifacts. For example, you can tag artifacts as follows:
|
||||
|
||||
In the Harbor interface, click on an artifact to see its current set of tags, then select the tag you wish to delete and click 'REMOVE TAG', and then click 'OK'
|
||||
|
||||
|
||||
|
||||
You can remove all tags from an artifact without deleting the artifact manifest itself. The artifact is still visible on the web console with nothing listed under 'Tags '
|
||||
|
|
@ -1,17 +1,19 @@
|
|||
---
|
||||
title: Retagging Images
|
||||
title: Retagging Artifacts
|
||||
weight: 75
|
||||
---
|
||||
|
||||
You can retag images in Harbor. Users with sufficient privileges can retag images to different repositories and projects. For example, you can retag images as follows:
|
||||
User with sufficient privileges can copy artifacts in Harbor to different repositories and projects. For example, you can copy images as follows:
|
||||
|
||||
- `release/app:stg` --> `release/app:prd`
|
||||
- `develop/app:v1.0` --> `release/app:v1.0`
|
||||
|
||||
To retag an image, you must have read permission (guest role or above) in the source project and write permission (developer role or above) in the target project.
|
||||
To copy an artifact, you must have read permission (guest role or above) in the source project and write permission (developer role or above) in the target project.
|
||||
|
||||
In the Harbor interface, select the image to retag, and click `Retag`.
|
||||
In the Harbor interface, select the artifact to copy, and click `Copy`.
|
||||
|
||||
|
||||
|
||||
|
||||
In the Retag windown, enter the project name, repository name, the new tag name, and click **Confirm**.
|
||||
In the Retag window, enter the project name, repository name, the new tag name, and click **Confirm**.
|
||||
|
||||
|
||||
Loading…
Reference in New Issue