[request] add sudo capability for the qt user in the container to allow changes to the running container

I just found out this project, and it could help me build Qt in CI without having to do the heavy lifting of rebuilding the Qt world... so first, thanks for that !

I am trying to build a Qt project leveraging Gitlab CI (it uses docker as base image) and use qt-build as a base image to do the build in... My CI script will take care of calling the right commands (cmake in my case).

Currently I get :

If you wanted to use the container to build a qmake project, you have to invoke the container with command "build" and mount the project to /var/build
Invoking container with command(s) sh -c if [ -x /usr/local/bin/bash ]; then
    exec /usr/local/bin/bash

How can I do that? Is there an example around ? I couldn't see anything in the doc, but maybe there could be another entrypoint for this usecase ?

After more investigation, this problem is because I currently cannot start the container as the root user, in order to install other packaged dependencies. see : https://gitlab.com/gitlab-org/gitlab/-/issues/23990

having sudo setup in the container, configured to work with the qt user would be another solution...

Well, first of all, I am glad that you found my project and find it useful. I am not really sure, whether I exactly get your point or not.

So you use the image in your ci pipeline to build your own project using your own scripts. This might or might not work, depending on what your own scripts depend on. You mentioned cmake, which my images do not provide (yet, I am currently planning to add cmake as an additional build option).

So calling cmake in your CI-Pipeline will most likely not work at all, if you do not provide a cmake binary via your repo content ;-)

The entrypoint in the Dockerfile is flexible, if invoked by Gitlab-CI/CD runners, the working environment is usually bash (unless you specify things differently in your .gitlab-ci.yml, where you can use entrypoint: [] as an override) because gitlab passes a shell selection command to start the container.

So any manual entrypoint override is considered not necessary.

This is a working basic example .gitlab-ci.yml, building the helloworld example from this repo:

image: darkmattercoder/qt-build:latest

build_test:
  tags:
    - docker
  script:
    - echo "this is only a test...."
    - cd helloworld
    - mkdir -p build
    - cd build
    - qmake -d ..
    - make
    - ./helloworld

Your planned approach to install "additional packaged dependencies" inside the running docker container is considered really bad practice. Docker containers should serve one purpose only, which is usually defined at build time. It might make sense to interact with a running container like this for testing purposes though, which I consider not the case in a ci environment.

So I only can guess, that you wanted to install cmake inside the container, correct?

You should not do that.

Instead, you should adjust the Dockerfile by yourself to install cmake at build time and make a gitlab ci pipeline build the image for you and push it into a public registry or into the registry on the machine where your runners live. The pipeline of the actual project can then make use of your own image for building the software. This should be more or less an easy job, given that the Image is based on ubuntu and thus cmake is quickly installable.

I am looking forward to integrate cmake soon as well.

Was my comment helpful?

Thanks for the detailed reply.

I had a deeper look and indeed I realized that even if the warning is displayed, my command was run. I was just distracted by the message in my use case, no worries there. So no real need for entrypoint override.

I dont want to start a long debate, but let me reply to your points before, and argument for the simple change I think would be beneficial...

Your planned approach to install "additional packaged dependencies" inside the running docker container is considered really bad practice. Docker containers should serve one purpose only, which is usually defined at build time. It might make sense to interact with a running container like this for testing purposes though, which I consider not the case in a ci environment.

For any system, docker or not:

It is a bad practice to expect the user having to add extra things for the application to run. Unconvenience
It is a bad practice to run services as root, hence using a dedicate user is usually preferred. Security issue.
It is also arguably a bad practice to prevent a user to customize the system to suit his needs. Unconvenience. How much he should be able to customize however, is always up for debate...

In my usecase, I am not building a docker file, and I have no intention to maintain a Dockerfile. Ideally the build process for a software should be in one place, and retrieving required dependencies is part of that build process. I would rely on the system packaged Qt version if it was compatible with the developed software, and use a bare Ubuntu container as build environment, but sadly it is not the case at the moment. On the other hand building the whole Qt from source would take too long, hence my choice to rely on a container where these are already built.

So I only can guess, that you wanted to install cmake inside the container, correct?

Yes, and more strange compilation/link/test/doc tooling, that you can never plan for in advance.

You should not do that.

Instead, you should adjust the Dockerfile by yourself to install cmake at build time and make a gitlab ci pipeline build the image for you and push it into a public registry or into the registry on the machine where your runners live. The pipeline of the actual project can then make use of your own image for building the software. This should be more or less an easy job, given that the Image is based on ubuntu and thus cmake is quickly installable.

It is not practical to do this for every compilation/link/test/doc tool that I want to add or change. Example : what if the version of make that is in the container now doesn't work with the software I m building for some strange reason ? Rebuilding the container everytime in order to test various make version is not a practical solution.

I am looking forward to integrate cmake soon as well.

I saw a few different issues of things you were planning to integrate. But what about the things that are not planned ? And in the mean time, users have to build and maintain their own docker images, just for testing this image and building their software with qt.

So here is a proposed solution : Have the qt user able to sudo. If necessary a user of that container can modify the contained environment as it suits his/her usecase. cmake, tools, custom script, etc. just when running the container. No need to rebuild anything other than the software he/she cares about.

So I'll try to do that in the next few days, and I ll let you know.

Thanks for your explanation. I still try to figure out what the potential risk of making sudo available for the qt user. And I am not sure, whether I should refuse to add that possibility or not.

However, a few thoughts that I want to add:

Performing several additional setup steps after the container started is not really performant
- It requires time and computing resources
- It leads to a reduced scalability
On the other hand, writing an own dockerfile that is based on the here provided ones, should be a one time effort and really does not require a lot of maintainance. It's what I and a lot of others do when it comes to customizing publicly available docker images
You would have the configuration of your tooling in one definitive place at hand, instead adding everything to the script: section of your gitlab CI/CD build job.
It would give you a nice and clean system ready to execute your actual build process fast and reproducible
You could always start docker containers as root using the -u root argument for docker run however this might require additional runner configuration in the runner config or using docker commands in the CI/CD file via an exposed docker socket.

Let me think it through. It might not be too harmful to allow the usage of sudo. But I need to collect some opinions before I can make a decision about it.

This is a quick example how easy such a modification would be:

Dockerfile:

FROM darkmattercoder/qt-build:latest

USER root

RUN apt-get update && apt-get -y install cmake

RUN echo "additional setup steps performed here...."

USER qt

Build and usage:

# docker build -t testimage:latest .
[+] Building 18.5s (7/7) FINISHED
 => [internal] load build definition from Dockerfile                                                                                                               0.1s
 => => transferring dockerfile: 204B                                                                                                                               0.0s
 => [internal] load .dockerignore                                                                                                                                  0.1s
 => => transferring context: 2B                                                                                                                                    0.0s
 => [internal] load metadata for docker.io/darkmattercoder/qt-build:latest                                                                                         0.0s
 => CACHED [1/3] FROM docker.io/darkmattercoder/qt-build:latest                                                                                                    0.0s
 => [2/3] RUN apt-get update && apt-get -y install cmake                                                                                                          17.1s
 => [3/3] RUN echo "additional setup steps performed here...."                                                                                                     0.4s
 => exporting to image                                                                                                                                             0.8s
 => => exporting layers                                                                                                                                            0.7s
 => => writing image sha256:8ea5ea439924ca5f5889e70d3ae71d69d906351668a5005a1e90eae632dff1dc                                                                       0.0s
 => => naming to docker.io/library/testimage:latest                                                                                                                0.0s
# docker run --rm -it testimage:latest bash
If you wanted to use the container to build a qmake project, you have to invoke the container with command "build" and mount the project to /var/build
Invoking container with command(s) bash...
qt@972cb7d881d6:~$ cmake
Usage

  cmake [options] <path-to-source>
  cmake [options] <path-to-existing-build>

Specify a source directory to (re-)generate a build system for it in the
current working directory.  Specify an existing build directory to
re-generate its build system.

Run 'cmake --help' for more information.

qt@972cb7d881d6:~$

darkmattercoder / qt-build

[request] add sudo capability for the qt user in the container to allow changes to the running container #23