Dockerfile builds everything twice

[saraedum]

The docker/Dockerfile uses a multi-stage approach to build several related images. However, something is broken since every SPKG is built (at least) twice during a run of .ci/build-docker.sh.

As a result, building docker images takes a very long time and, with this bug, likely exceeds the limits of most CI providers.

CC: @koffie @dimpase @videlec

Component: docker

Issue created by migration from https://trac.sagemath.org/ticket/32998

[saraedum]

comment:1

(I am building 9.3 and 9.4 images locally. Assuming that it succeeds, I can push them to docker hub but it might take all day for that build to finish.)

[mkoeppe]

comment:3

One thing to watch out for is the time stamps in SAGE_LOCAL/var/lib/sage/installed and SAGE_VENV/var/lib/sage/installed.

[dimpase]

comment:4

Docker build can use more system packages...

[saraedum]

comment:5

Replying to @dimpase:

Docker build can use more system packages...

Sure, but that just helps with the symptom here I think. Also, the idea of these docker images were that they are the actual SageMath distribution. In particular, the idea was that these images can be used to test SPKG changes by supporting incremental builds. For this we must not use system packages. That might not be what we want here anymore.

[koffie]

comment:6

The wish for to the sagemath-dev image being the actual distribution makes sense.

For the regular sagemath image this wish is I guess less relevant, but having two different build setups for the sagemath-dev and sagemath image doesn't really makes sense to me, since it will mean more maintenance.

The time limit for ci jobs on github is 6 hours per job for what it is worth.

[dimpase]

comment:7

Replying to @saraedum:

Replying to @dimpase:

Docker build can use more system packages...

Sure, but that just helps with the symptom here I think. Also, the idea of these docker images were that they are the actual SageMath distribution. In particular, the idea was that these images can be used to test SPKG changes by supporting incremental builds.
For this we must not use system packages. That might not be what we want here anymore.

There are many packages that change quite infrequently, yet take lot of time to build.

If there is an image only allowing changes in sagelib, it would already be quite useful.

As well, I don't even understand why using system packages is any different - do you mean to say that docker images don't allow monkey-patching?

[saraedum]

comment:8

As well, I don't even understand why using system packages is any different - do you mean to say that docker images don't allow monkey-patching?

No. The GitLab CI setup supports (modulo this very issue here) incremental builds. So, the idea was that you can perform an SPKG change in a ticket here (something which the patchbot does afaik not support.) The CI then incrementally builds a docker image starting from sagemath-dev with that SPKG upgraded. That docker image can then be tested with tools such as https://gitlab.com/sagemath/gitlab-sage which is deployed here at the moment: https://gitlab-hooks-flau3jeaza-ew.a.run.app/

An actual demo of this would be the (outdated) build for #28466 at https://gitlab-hooks-flau3jeaza-ew.a.run.app/status/trac/branch/u%2Fgalois%2Fmrs%2F32%2Fgeneral-extensions but it works equally for any other branch. (i.e., it doesn't because the GitLab builds are not functional at the moment.)

Of course this also works for non-SPKG changes. The idea was to be able to better review changes proposed on a ticket without having to run the rebuild of SageMath locally. However, in the end there was not that much interest in this feature.

[dimpase]

comment:9

Replying to @saraedum:

As well, I don't even understand why using system packages is any different - do you mean to say that docker images don't allow monkey-patching?

No. The GitLab CI setup supports (modulo this very issue here) incremental builds. So, the idea was that you can perform an SPKG change in a ticket here (something which the patchbot does afaik not support.)

You can perform an SPKG change from a system-wide package foo to a Sage-provided one, by doing make foo && make build. You can also go back to a system package (assuming it's accepted by ./configure, naturally), by make foo-clean && ./configure && make build