Import labels from Dockerfile

[djsnoopy]

As requested from Wang Yan i´ll file the feature request to import labels from Dockerfile.

You already seem to import the maintainer label. It would be nice if the labels column would show the labels which exists in the Dockerfile. So users can search for images based on labels or use the labels as additional meta information for the image.

I. ex.: I just created an image which contains centos, openJDK, hybris and a JDBC driver. I added labels with specific informations about the versions of each element. LABEL os="${OSVERSION}" LABEL jdk="${JDKVERSION}" LABEL hybris="${HYBRIS_PACKAGE}" LABEL jdbc="${JDBC_DRIVER}"

Any discussions are highly appreciated

requirement

1. if any user adds labels in their image, when you import that image into Harbor, import and attach the labels to that image as well. So labels from Docker are exposed as labels in Harbor
2. [out of scope] Go back to existing images that were imported in Harbor and discover their labels (we can do this in a future release if users ask for it)

[xaleeks]

Since Harbor labels currently are not k:v pairs, will this introduce a new k:v structure to Harbor, and if so should be this new structure be intact called 'labels' and the current harbor 'labels' need to vacate this title and find some other name. Or are we translating Dockerfiles labels into harbor labels so that the k:v information would need to be condensed into a single string

[xaleeks]

2. [out of scope] Go back to existing images that were imported in Harbor and discover their labels (we can do this in a future release if users ask for it) Just double checking, this is referring to backfilling the images on harbor instances right now coming from docker but without previously imported labels?

[JordanSussman]

I envision this functionality enabling additional workflows that aren't currently possible with Harbor. For example:

Replication based on docker label

This functionality could start the work to greatly simplify the replication process workflow that I'm considering implementing. Today, the filters for replication are somewhat limiting, and instead I'd prefer to utilize metadata that we are already adding as labels to our build process to determine if the image should be replicated. A very brief example of how I envision this workflow looking:

FROM alpine:latest
LABEL replication=china

Resource filter: docker label Pattern: replication=china

Result: replication to china harbor instance

Tag retention based on docker label

The tag retention policies capability could be expanded to include checks for images containing or lacking specific docker labels.

Enhanced search

Our current build process adds labels to track author, pull request (true or false), git org/repo, build server, etc. It would be helpful to query harbor to tell me how many images included the specific author or originated from a specific build server.

[webmutation]

interest in this i have

[vzanlnx]

I Also have interest in this feature. Would be very helpful to give more granularity in our pipeline process.

[sethbergman]

I've been able to get this working in GitLab CI by using a for loop and iterating through the Dockerfile(s).

Simple version

variables: 
  DOCKERFILE: Dockerfile
  HARBOR_SERVER: harbor.example.com
  HARBOR_NAMESPACE: docker
script: |
  for DOCKERFILE in $DOCKERFILE
  do 
   DOCKER_IMAGE=$HARBOR_SERVER/$HARBOR_NAMESPACE/$CI_PROJECT_NAME:$CI_PIPELINE_ID
   LABELS="--label commit.sha=$CI_COMMIT_SHA --label project.url=$CI_PROJECT_URL 
   --label pipeline.url=$CI_PIPELINE_URL"
   docker build $LABELS --no-cache -t $DOCKER_IMAGE . -f $DOCKERFILE
   docker push $DOCKER_IMAGE
  done

[webmutation]

Hi @sethbergman I am not sure sure I understand how these tags are being passed to Harbor Labels... do you do an API call to Harbor somewhere after in the script?

Because that snippet only adds the labels to the build, afaik not what this issue is about. This issue is about getting the labels that are on the Docker image to be imported as Harbor labels... for this we can do an API calls to Harbor but it would be nicer if another more efficient mechanism was in place.

[senk]

I guess you wanted to tag @sethbergman

[timchenxiaoyu]

useful function

[Andreiaotto]

Hello, any plans to have this feature added? Would be great as we are using labels for replication, teams are already used to have their labels in Dockerfile.

Thank you!

[tianon]

FWIW, the OCI decided to call these "image annotations" instead of "labels" which might help with differentiating them from Harbor's "labels": https://github.com/opencontainers/image-spec/blob/v1.0.1/annotations.md

[github-actions[bot]]

This issue is being marked stale due to a period of inactivity. If this issue is still relevant, please comment or remove the stale label. Otherwise, this issue will close in 30 days.

[lindhe]

I think this should be kept open.

[Timmmm]

How does this relate to the Annotations field which appears to be a K:V set, and the OCI spec linked there talks about author, description, etc.

If I set LABEL description=... in my Dockerfile should I expect it to show up in that column (pretty sure I've tried that and it doesn't unfortunately).

[VJGOPAL]

Hi @sethbergman I am not sure sure I understand how these tags are being passed to Harbor Labels... do you do an API call to Harbor somewhere after in the script?

Because that snippet only adds the labels to the build, afaik not what this issue is about. This issue is about getting the labels that are on the Docker image to be imported as Harbor labels... for this we can do an API calls to Harbor but it would be nicer if another more efficient mechanism was in place.

could you please share how to authenticate the API calls to assign the label via workflow

[VJGOPAL]

@webmutation, Please, could you share how to authenticate the API calls to assign the label via workflow