WIP prebootstrapped CI images
- Dec 01, 2020
-
-
Georges Racinet authored
These are now provided by the dedicated image with chromium. We keep only the sudoers configuration (allowing the user running the tests to call `gitlab-ctl` and friends).
-
Georges Racinet authored
The problem seemed to be related to just initialized instances. Let's hope our prebootstrapped ones don't suffer for it. In any case they create motivation to remove unnecessary latency, since they start much faster. Ideally, we should just have a better detection of the condition with retry provided by the Heptapod and Project classes. We'll see.
04251705c6be
-
- Nov 30, 2020
-
-
Georges Racinet authored
A later problem is that we will need to also produce the 'testing' image (or maybe have omnibus produce it for tag builds only, or just get rid of it entirely). Attempts at building the two images in a single call so far have failed. Notably, --cache will want to push its cached layers to a local registry, defaulting to registry.h.n to which upload is very slow. Also, it is not clear what the end step would be after running Kaniko twice in the same filesystem (not what Kaniko is designed for). Perhaps we can hope for a new Kaniko feature to become available later on, like pushing two build stages defined in a single Dockerfile? In the mean time let's just accept the possibility of an unnecessary pull of the bootstrapped image (not so grim).
-
Georges Racinet authored
Building on top of the bootstrapped image precendently added, this one has the dependencies for heptapod-test to run inside the image, hence what's needed for the docker-inside jobs (fs_access, services). It is fat, more than 400MB
4b88739c923c -
Georges Racinet authored
The idea is that the initialization that occurs so far in all our CI jobs is lengthy and resource intensive: it accounts to about 5 minutes per job. For true installations, it makes sense to perform these steps with an initial configuration that's already as intended. But for our tests, the result is always the same for a given base image. Because the affected directories are volumes, we need to copy the result elsewhere on the filesystem, so that they aren't discarded immediately. In turn, the wrapper script used in the bootstrapped image restores them to the volumes and performs a much simpler startup sequence. The base image to use is entirely passed as an ARG, but it will typically be called by CI, perhaps with a hash-based tag.
b1a87f120855
-