Skip to content
Snippets Groups Projects

WIP prebootstrapped CI images

Open Georges Racinet requested to merge topic/default/prebuilt-images into branch/default
  1. Dec 01, 2020
    • Georges Racinet's avatar
      Heptapod CI: removed unnecessary install steps in "inside" tests · 6c0bc511c182
      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).
      6c0bc511c182
    • Georges Racinet's avatar
      Heptapod CI: reducing additional wait time. · 04251705c6be
      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
  2. Nov 30, 2020
    • Georges Racinet's avatar
      Heptapod CI: building bootstrapped images with Kaniko · 306720477f5b
      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).
      306720477f5b
    • Georges Racinet's avatar
      CI: image with chrome-driver · 4b88739c923c
      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's avatar
      CI: new data bootstrapped image · b1a87f120855
      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
Loading