Publish the Docker image to a public repository

[homme]

This would save a casual user who is investigating the tool from having to set up a build environment and create the image themselves: users may not have such an environment available to them and are unlikely to spend the time setting it up (I'm one such user!).

[sschuberth]

I would regard that to be a part of https://github.com/oss-review-toolkit/ort/issues/1901, but I'll leave this issue open to make the request explicit.

[JeroenKnoops]

We also need official docker images for this.

Currently we're occasionally creating a docker-image from the master and tag them with a date timestamp since we want immutable images for analyzing our code.

We do this by including the repo as as submodule in our repository: https://github.com/philips-software/docker-ort

Docker images van be found here: https://hub.docker.com/r/philipssoftware/ort/

[tsteenbe]

We did not publish an Docker image for ORT as the ORT maintainers would like to be compliant with the FLOSS licenses contained in such an ORT Docker image. We can easily generate SBOM for ORT itself but not for the rest of the tools that would make up such a ORT Docker image. Ideally, we build the ORT Docker image from scratch so we can publish the image and corresponding source code but that's not an easy task since we use a layered Dockerfile. We welcome contributions to help us get this done.

[tsteenbe]

Happen to stumble upon https://buildpacks.io that help you build Docker images and this come with a basic BOM out of the box. No integration for GitHub yet but there is for GitLab

[JeroenKnoops]

I'm looking into using buildpacks to build an image. They seem to better handle dependencies in different layers.

Problem

Currently I'm facing the following problem: After a few small changes, I am able to build ORT with buildpacks, but the tests fail.

The tests require a lot of tools (conan, dep, composer, bundle, cargo, etc) to be present in build environment. Buildpacks do not see these out-of-the box.

Options

Option 1. Split tests

All test related to different tools should run as separate tests so we can tell buildpack what tools need to be installed for that particular testset. F.e. the tests involving Ruby eco systems, should be separated from the rest and can be performed in parallel with the correct environment installed for that use-case.

Disadvantage

• Setup splitting tests in gradle takes time.
• We will not have 1 docker image containing all default build environments.

Advantage

• Tests run faster and are less brittle to specific build environments.
• With 1 big docker image containing all possible build environments people take in a lot of code they don't need. When I'm using ORT for a python project, I don't need the dotNet environment. I need python and I want to be in control of the version of python. In the current setup, it's hard to overrule a certain version of a tool which is in the base image. I ended up in building ORT from scratch and use the jar in the existing project build environment. With the split approach we should be able to make language specific smaller images with only the required build tools. These are also less complicated so if a user wants to use another version of the tool, it's more easy to adjust.

Option 2. Re-create 1 build environment with specific versions of tools.

Recreate one build environment with specific versions of the tools and use this for both testing / building ort and for the docker image.

Advantage

• We have the blueprint available in dockerfile. We can convert it to a buildpack stack.

Disadvantage

• Docker image might be to restricted to specific versions of tools installed. Maybe there should be a way to easily select other versions of tools.
• Docker image has a lot of tools you're not using in your project.

Plan

I will make a PoC of Option 1 for one language. Maybe we then can evaluate these Pros and Cons.

[sschuberth]

Also, in parallel we should generally aim for reducing the number of required external tools. I have a few ideas how to do that, but not the time to implement it 😞

[sschuberth]

We did not publish an Docker image for ORT as the ORT maintainers would like to be compliant with the FLOSS licenses contained in such an ORT Docker image.

@mkurzman recently proposed to me to make use of OSADL's pre-cleared base Docker images which are also published to Docker Hub. That way we at least wouldn't need to care about the base image's compliance anymore.

[NicolasToussaint]

Any advances on this topic ? We would like to publish our ORT template in the to be continuous program, but that would require a publicly available ORT Docker image.

[sschuberth]

Any advances on this topic ?

Not really, as AFAIK no one is actively working on it / had an urge to move this forward so far.

[nicorikken]

When it comes to generating an SBOM we could also use Tern https://github.com/tern-tools/tern Recent versions should be able to also detect licenses of typical distribution packages. The SBOM could be provided alongside the container image. As a further mitigation we could dogfood ORT and use it to evalute the container SBOM for certain criteria.

[nicorikken]

Generating an SBOM using Tern for the current ORT container takes about 35 minutes on GitHub Actions. In the meantime I also found Syft which is another tool for creating SBOMs of containers. I might give that a try as well.

For now I started generating images on a daily cron schedule: https://github.com/alliander-opensource/ort-container/pkgs/container/ort-container I used the Philips container in the past but that hasn't been updated in a while so I took a more radical approach. Let's see what comes of it.

I'm still looking for suggestions on how to publish SBOMs alongside container images: https://github.com/tern-tools/tern/discussions/1183

[nicorikken]

Containers are now available at https://github.com/orgs/alliander-opensource/packages?repo_name=ort-container including a dedicated build for the PR #4746

[nicorikken]

Discussed at community at 25th of August::

License compliance as requirements including providing source code.

From there we can improve it, like the desire to scan ORT with ORT, for which so far nobody succeeded.

[tsteenbe]

@nicorikken @heliocastro and @tsteenbe are working on creating a ORT "sources" image e.g. the complete corresponding source code to satisfy open source license obligations.

If people are interested in joining this effort please reach out to me to be added to our sync meetings/slack channel on this topic.

[sschuberth]

From there we can improve it, like the desire to scan ORT with ORT, for which so far nobody succeeded.

I've filed #5696 for that.

[pismy]

Hey I understand the reason why you decided not to publish the Docker image to a public registry, but I also think this choice prevents your great tool from becoming more successful. We would like so much to implement a GitLab CI/CD template for ORT (see to-be-continuous templates)...

[sschuberth]

I guess publishing to Docker Hub is out of the question now, so if at all we should probably go straight to GitHub's Container Registry.

[itrich]

I guess publishing to Docker Hub is out of the question now, so if at all we should probably go straight to GitHub's Container Registry.

I'd totally agree on pushing the Docker image to https://ghcr.io. We've realized this with a pretty straight-forward workflow: https://github.com/SovereignCloudStack/ort-docker/blob/main/.github/workflows/build_docker.yml

[NicolasToussaint]

Is there maybe any moves concerning a possible publication from the ORT community to ghcr.io ?

[heliocastro]

So, we're not published only because @tsteenbe want us to have fully scanned and with BOM's The pipeline need 5 lines to publish in the end, would be pretty much instant and is ready. So, blame me to not really have time to finish this. @nicorikken This is a best possible approach to use btw, https://github.com/anchore/syft

[NicolasToussaint]

Thanks @heliocastro for your reply ;

I'm not blaming anyone, just asking :-D Could just as much blame myself for asking rather than contributing !

[sschuberth]

Docker images are now available in GHCR.