Package/container linking via label not working

According to the Web UI and the documentation, you can either link a container manually on the web (which works), or you can link it by setting the org.opencontainers.image.source label on the pushed container. I have tried with various containers and repositories, but have been unable to get it to link using the label.

At first I thought it might be because my Dockerfile was named Containerfile (the new more generic standard) and that maybe GitHub was parsing Dockerfiles for some reason instead of reading the labels directly from the container image. I tried creating a new test repository using Dockerfile instead of Containerfile but it still didn’t work.

I also tried rebuilding and pushing a new version of the container after I had made sure I had created/pushed to the git repository. That should work if GitHub was only attempting to link containers to repos when the container was pushed, but not if the repo was created or pushed to after the container was already pushed. That also did not work.

I am not sure if I am doing something wrong, or if GitHub itself is buggy.

Test container: Package test-ctr · GitHub
Test repo: GitHub - computator/test-ctr

Hi @computator,

I think you might be missing an =.

Could you try this instead?

LABEL org.opencontainers.image.source=https://github.com/computator/test-ctr

Please let me know if it works!

@jcansdale I do not believe that’s the issue. Both forms are valid syntax and you can see the label is created correctly:

$ podman inspect ghcr.io/computator/test-ctr -f '{{ .Labels | json }}' | jq .
{
  "io.buildah.version": "1.19.4",
  "org.opencontainers.image.source": "https://github.com/computator/test-ctr"
}

I did update the Dockerfile and rebuild the container just in case though, and after pushing both of those it still hasn’t worked.

I’ve created a PR with a simple workflow that builds and publishes an image:

Could you try adding a repo secret called WRITE_PACKAGES_TOKEN that contains a PAT with the write:packages scope and merge this PR?

You can see it appears to have worked under my test account:

Well that seems to have linked properly. I did pretty much the exact same thing locally on my computer though before, so maybe Github isn’t properly detecting the label unless the container is pushed from in a workflow?

I just noticed, if you compare the old version and the new one, the old one doesn’t have any labels. The image I manually pushed definitely has them though per my third post, so something must be causing them to be dropped.

Previous: https://github.com/users/computator/packages/container/test-ctr/2477476
Latest: Package test-ctr · GitHub

Ah that’s it! Github isn’t keeping labels when pushing images using the standard OCI format. If I push the exact same build using the docker format it keeps the labels and it works.

OCI: https://github.com/users/computator/packages/container/test-ctr2/2524050?tag=latest
Docker: https://github.com/users/computator/packages/container/test-ctr3/2524068?tag=latest

Hi @computator,

How do you mean using the standard OCI format? Is this is Dockerfile difference or command line tool?

OCI is a specification for various container related technologies. For example, runc is an OCI compliant container runtime and is what docker (and many other container engines) uses to run containers. The OCI image spec is the standardized format that container images are stored in. Docker contributed their v2s2 format as the base for the OCI image spec, and containers can be converted back and forth between the two formats.

Docker itself can output either format but still defaults to their proprietary one. Most other container infrastructure I am aware of supports either format but defaults to using OCI images. For example Red Hat’s CRI-O Kubernetes runtime defaults to OCI. In addition, RHEL has switched over to using podman (a drop in docker replacement/improvement) in RHEL8 and later and it defaults to OCI as well.

There is no difference in Dockerfiles or anything, nor in the built images. Just the format they are stored or transmitted as. I use podman on Ubuntu, and in my last post I pushed the same exact image twice, just one transmitted as oci, and one transmitted as docker v2s2.

Edit: Meant to include this link GitHub - opencontainers/image-spec: OCI Image Format

1 Like

Hi @computator,

Docker itself can output either format but still defaults to their proprietary one. Most other container infrastructure I am aware of supports either format but defaults to using OCI images.

Thanks for the background info!

I’ve reproduced what you said in this workflow:

Only the podman-test-docker image is linked to the repo:

I’ll let the GitHub Packages team know about this limitation.

3 Likes

Hi,

I’ve just run into this same issue and came across your posts here - so thanks for digging into this and posting.

Until GHCR can pick out and use the org.opencontainers.image.source label from the OCI container format, a workaround is to ask podman to push the image using Dockers v2s2 format.

podman push --format=v2s2 ghcr.io/danham/imagename:v1

As you know, GHCR is able to read the required labels when the image manifest is in this format and as such, can correctly link an image to a repo.

2 Likes

Hi @jcansdale,

I was just wondering if there’s any updates on getting this fixed? I was reminded of this issue today after reading an article about how Red Hat has nearly 50% market share by revenue of the container technologies market. Since they are the driving force behind podman I would expect more and more people will run into this.

Thanks!