Location for ghcr containers

[erikbosch]

I noticed that we have used different naming/path for ghcr containers. In this repo we do not use the pattern <orga>/<repo>/<component> but rather <orga>/<component>. This is different compared to for example kuksa-python-sdk, and should better be aligned, and if so better know when the new repos are quite new.

FYI: @SebastianSchildt @mikehaller @lukasmittag

This repo

https://github.com/eclipse-kuksa/kuksa-databroker/pkgs/container/kuksa-databroker

docker pull ghcr.io/eclipse-kuksa/kuksa-databroker:main

https://github.com/eclipse-kuksa/kuksa-databroker/pkgs/container/kuksa-databroker-cli

docker pull ghcr.io/eclipse-kuksa/kuksa-databroker-cli:main

Other repos

https://github.com/eclipse-kuksa/kuksa-python-sdk/pkgs/container/kuksa-python-sdk%2Fkuksa-client

docker pull ghcr.io/eclipse-kuksa/kuksa-python-sdk/kuksa-client:main

[SebastianSchildt]

Not a strong opinion, but thinking 5 seconds about it, I like the version without repo better. Less clutter, and everything here IS kuksa (that was different in the older eclipse orga)

I am, however, not sure if any best practices exist here in Github or in general, for naming containers

[erikbosch]

It should not be a big problem removing container name - our containers typically have specific/unique names so no risk for conflicts. But if we go that path we need to decide what to do with "other repos". Updating build actions is simple, but the question is if we should recreate the currently tagged versions. I do not know what happens if you update the buildaction but trigger it for an older version - if you then will build according to latest buildaction, but use the tag as source version

[erikbosch]

And we have off course the pragmatic approach, keep current location for all containers we have created so far. Could actually be a good option to not risk having "duplicated" containers.

[erikbosch]

Discussion resolved, closing this one