[Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services

Eric Anholt eric at anholt.net
Fri Feb 28 19:37:03 UTC 2020


On Fri, Feb 28, 2020 at 1:20 AM Eero Tamminen <eero.t.tamminen at intel.com> wrote:
>
> Hi,
>
> On 28.2.2020 10.48, Dave Airlie wrote:
> >> Yes, we could federate everything back out so everyone runs their own
> >> builds and executes those. Tinderbox did something really similar to
> >> that IIRC; not sure if Buildbot does as well. Probably rules out
> >> pre-merge testing, mind.
> >
> > Why? does gitlab not support the model? having builds done in parallel
> > on runners closer to the test runners seems like it should be a thing.
> > I guess artifact transfer would cost less then as a result.
>
> Do container images being tested currently include sources, build
> dependencies or intermediate build results in addition to the installed
> binaries?
>
>
> Note: with e.g. Docker, removing those after build step doesn't reduce
> image size.
>
> You need either to do the removal in the same step, like this:
> --------------------------------------------------------
> RUN git clone --branch ${TAG_LIBDRM} --depth 1 \
>      https://gitlab.freedesktop.org/mesa/drm.git && \
>      cd drm  &&  mkdir build  &&  cd build  && \
>      meson --prefix=${INSTALL_DIR} --libdir ${LIB_DIR} \
>        -Dcairo-tests=false ../  && \
>      ninja  &&  ninja install  && \
>      cd ../..  &&  rm -r drm
> --------------------------------------------------------
>
> Or use multi-stage container where the final stage installs just
> the run-time dependencies, and copies the final (potentially stripped)
> installed binaries from the build stage.

Our container builds already contain all the cleanup and don't do
multi-stage builds.  If you have concerns about container size, I
recommend picking a job using a container, pulling that container, and
going in and taking a look around instead of speculating.


More information about the mesa-dev mailing list