Run every library testing job in one docker image (#295)

[adrpo]

The last open box of #295:
"Use docker images for the Jenkins LibraryTesting so is easier to maintain".

Only the wasm-jit target ran in a container. Every other job ran on the node
itself, so each machine had to carry - installed and kept up to date by hand -
the compilers, the python environment, omc, FMPy and whatever the tested
libraries need to build. That is what a job silently depends on today, and what
has to be reproduced on a new machine before a job can move to it.

The image wasm-jit already used becomes the image of every job, moved from
.CI/wasm-jit to .CI/testing, and the dockerfile parameter of
runRegressiontest defaults to it: a target now opts out of the container
(dockerfile: '') instead of into it. A node needs docker, git and an ssh key,
and a job moved to another machine tests what it tested before.

What the image gained

autoconf, automake, libtool, omniidl, libomniorb4-dev	The targets that do not ask for a cmake omc still build through autoreconf && ./configure --with-omniORB; the base image carries what the cmake build needs, which is not the same set.
FMPy	The simulator of the -fmi-fmpy targets. The job used to pip install FMPy per build, which inside a container would be thrown away with the container. The version is the image's now, and the build only checks that the interpreter test.py reaches has it.

What moved into the container

Besides the omc build and test.py, which is what wasm-jit already ran
there:

• the OMSimulator build - a binary linked against the node's libraries need
  not load inside the image, and it is test.py, inside, that runs it;
• the conversion script - it runs the omc that was just built, which is
  now a binary of the image.

Installing the libraries and unpacking the reference files stay on the node:
they use the node's own omc. /mnt/ReferenceFiles is bound into the container
under its own path, so the reference results the maintenance job installs are
the same files on both sides, including the hash test.py writes next to one.

The image is tagged after the Dockerfile rather than after the job, so a node
keeps one image instead of one per job it has ever run.

What to watch on the first run

• The nodes need docker. wasm-jit runs on ryzen-9950x; the other jobs
  run on ryzen-5950x-1 and ryzen-5950x-2-1, which have to be able to run
  containers and to reach docker.openmodelica.org before this is merged and
  scheduled.
• The toolchain under every branch changes at once. The models are compiled
  by the image's compiler and linked against its libraries rather than the
  node's, so the first run of master, the FMI jobs and the C++ jobs may look
  like a wide regression - simulation times are flagged at 1.7x - and a model
  may change state for a reason that has nothing to do with omc. It is a
  one-off shift, and after it every machine measures the same thing.
• Library dependencies the nodes have and the image does not. The
  Dockerfile carries the ones we know of (libcomedi-dev, libx11-dev, Python
  3.8/3.12 for Buildings, jinja2); a library needing something else will say
  so in its build log, and the fix is a line in the Dockerfile rather than an
  apt-get install on each machine.

The image itself was not built while preparing this: no docker on the
machine this was written on. The Jenkinsfile parses, and every package the
Dockerfile adds resolves on ubuntu:26.04 (resolute), but the first build of
the image is the first real test of it.

---

generated by Claude Code

[AnHeuermann]

I would move the containerization to the upmost point in the Jenkinsfile. Something like:

stage('v1.26') {
  agent {
    docker {
      image 'docker.openmodelica.org/build-deps:ubuntu-26.04
      label 'ryzen-5950x-1'
      customWorkspace 'ws/OpenModelicaLibraryTestingWork'
      // --user so files in the workspace stay owned by the Jenkins user;
      // mount the caches/DB socket the run needs
      args '--user root:root -v /var/lib/jenkins/.cache:/cache -e HOME=/cache'
      alwaysPull true
      reuseNode true
    }
  }
  options { skipDefaultCheckout() }
  when {
    beforeAgent true
    expression { params.v1_26 }
  }
  steps {
    runRegressiontest('maintenance/v1.26', 'v1.26', '', '', false, '', '', false, false)
  }
}

Maybe use a variable for the image instead of hard coding it in any stage

[AnHeuermann]

We can also create a custom Docker image for testing. No build dependencies, just what a user would have installed. A GitHub workflow can build and upload the image every time it changes. Similar to https://github.com/OpenModelica/build-deps just in this repo.

[sjoelund]

I would move the containerization to the upmost point in the Jenkinsfile.

That messes a bit with the dockerfile since the requirements are copied into there

[sjoelund]

Seems fine. Can of course be fine-tuned. And like Andreas said, we could also use 2 different images - 1 to build and 1 to run. That would make it more clear that we want the separate build step rather than a docker agent

[AnHeuermann]

@adrpo after this is merged I'll do the switch to the CMake build.
After that we can try splitting up the images for building and testing in another PR.

[sjoelund]

Keep in mind we still build 1.26 and 1.27. So their cmake builds probably also need to work (or use a Dockerfile to install them from our apt repo and test using that)