Run every library testing job in one docker image (#295) - #335
Conversation
Sorry, something went wrong.
Only the wasm-jit target ran in a container; every other job ran on the node itself and needed the compilers, the python environment, omc, FMPy and the packages of the tested libraries installed there by hand - which is what OpenModelica#295 asks to be rid of. The image the wasm-jit target already used becomes the image of all of them, under .CI/testing rather than .CI/wasm-jit, and `dockerfile` defaults to it, so a target opts out of the container instead of into it. A node then needs docker, git and an ssh key, and a job moved to another machine tests what it tested before. What the image gained for the targets that did not have one: - autoconf, automake, libtool and omniORB, which the targets that do not ask for a cmake omc need: those still go through `autoreconf && ./configure --with-omniORB`, and the base image carries what the cmake build needs. - FMPy, the simulator of the -fmi-fmpy targets. The job used to `pip install` it per build, which in 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. Moved into the container along with the omc build and test.py, because they run the binaries the container will run rather than the node's: - 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, which runs the omc that was just built. Installing the libraries and unpacking the reference files stay on the node: they use the node's own omc, and /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. The image is tagged after the Dockerfile rather than after the job, so a node keeps one of them instead of one per job it has ever run.
AnHeuermann
left a comment
There was a problem hiding this comment.
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
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
That messes a bit with the dockerfile since the requirements are copied into there |
Sorry, something went wrong.
sjoelund
left a comment
There was a problem hiding this comment.
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
Sorry, something went wrong.
|
@adrpo after this is merged I'll do the switch to the CMake build. |
Sorry, something went wrong.
|
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) |
Sorry, something went wrong.
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
What moved into the container
Besides the omc build and test.py, which is what wasm-jit already ran
there:
not load inside the image, and it is test.py, inside, that runs it;
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
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.
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.
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