provide the docker image outside of ghcr.io

[GitMensch]

we do have a pretty full featured docker image already, would it help to re-use that [...]?
the problem would be where to host the image, as the images on ghcr.io cannot be accessed without a github token.

Originally posted by @milianw in #445 (comment)

Providing it directly in the docker hub would be an option: https://programatically.com/how-to-upload-docker-image-to-docker-hub/ - maybe it could be a general "KDAB development docker image" containing everything QT + KDE that is necessary for any projects you work on?
If the projects itself, like KDDockWidgets, are installed into separate directories, then even those can be build in a "clean" environment as long as the install directory of the installed version is not given to cmake.

Maybe other places or "base dev image" along with "images built on this" are better - I'm no docker person, so I can't tell...

[milianw]

a general container isn't really meaningful I believe, but I can see what we can do with the free tier at docker hub. I certainly don't want to pay for hosting that image

[GitMensch]

Maybe it is possible to create and share (in the scripts that use this) a token that only is enabled to pull the necessary containers? A simple change will otherwise always create errors in forks because of permission denied, see https://github.com/GitMensch/hotspot/actions/runs/6506394050/job/17671853987#step:2:18 for example.

[GitMensch]

re-reading https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-container-registry#pushing-container-images the biggest issue is that at least some of the published container images are on the default visibility: private according to this doc you can directly go to org, then to the package list and then switch each one you like a public (please provide at least the ones that are part of the workflows https://github.com/KDAB/hotspot/blob/master/.github/workflows/compile-and-test.yml and https://github.com/KDAB/hotspot/blob/master/.github/workflows/build-appimage.yml:

• ghcr.io/kdab/hotspot-ubuntu20.04-dependencies
• ghcr.io/kdab/hotspot-ubuntu22.04-dependencies
• ghcr.io/kdab/hotspot-archlinux-dependencies
• ghcr.io/kdab/hotspot-fedora34-dependencies
• ghcr.io/kdab/hotspot-opensusetumbleweed-dependencies
• ghcr.io/kdab/hotspot-neonqt6-dependencies <- seen as problematic before
• ghcr.io/kdab/kdesrc-build

Thank you very much!

And please consider to add the optional packages to hotspot-ubuntu22.04-dependencies as this ensures that the CI uses these for building and testing, too:

-- The following features have been disabled:

 * debuginfod, libdwfl and libdebuginfod are useful for on-demand fetching of debug symbols

-- The following RUNTIME packages have not been found:

 * LibRustcDemangle, Demangling for Rust symbols, written in Rust., <https://github.com/alexcrichton/rustc-demangle>
   Demangling of Rust symbols
 * LibDDemangle, Demangling for D symbols, written in D., <https://github.com/lievenhey/d_demangler>
   Demangling of D symbols

-- The following OPTIONAL packages have not been found:

 * KGraphViewerPart, KGraphViewer (from KDE extragear) is a tool to display graphviz .dot graphs, <https://invent.kde.org/graphics/kgraphviewer>
   Call graph in the caller/callee tab

[GitMensch]

@milianw - I've just rechecked, all container images used are public but ghcr.io/kdab/hotspot-neonqt6-dependencies which still seems to be in the default visibility "private" - can you adjust this (docs linked above)?

[milianw]

done

[GitMensch]

Thanks - using the workflow in forks should work now. This is useful (while possibly still needing to be logged in, if the policy for ghcr is the same as with getting artifacts ).

This possibly leaves open (haven't checked yet, will when I get back to check "use KDAB docker images for gitpot":

add the optional packages to hotspot-ubuntu22.04-dependencies as this ensures that the CI uses these for building and testing, too:

-- The following features have been disabled:

 * debuginfod, libdwfl and libdebuginfod are useful for on-demand fetching of debug symbols

-- The following RUNTIME packages have not been found:

 * LibRustcDemangle, Demangling for Rust symbols, written in Rust., <https://github.com/alexcrichton/rustc-demangle>
   Demangling of Rust symbols
 * LibDDemangle, Demangling for D symbols, written in D., <https://github.com/lievenhey/d_demangler>
   Demangling of D symbols

-- The following OPTIONAL packages have not been found:

 * KGraphViewerPart, KGraphViewer (from KDE extragear) is a tool to display graphviz .dot graphs, <https://invent.kde.org/graphics/kgraphviewer>
   Call graph in the caller/callee tab

Apart from this there's the main question of making the images available with the free docker tier, but I don't see a high priority in this any more (still would like to see that "somedayTM", so would prefer to leave this issue open).

[milianw]

the appimage base has all optional deps, there's no big value in providing everything everywhere