On Wed, 2018-08-29 at 14:11 +0100, Emil Velikov wrote: > Hi Juan, > > I've shared a number of suggestions. I'll leave that to you if they > will be in v3 or patches on top. > > On 29 August 2018 at 11:12, Juan A. Suarez Romero <jasua...@igalia.com> wrote: > > > In order to build the images, Rocker is used. This is a tool that > > extends the Dockerfiles with new features that are quite interested > > here. The main features we use is the support for templating, and the > > support for mounting external directories during the image building. > > This help to use tools like ccache to improve the build speed. > > > > I think that gitlab-ci supports templating - not sure about mounting > external directories.
We need the templating in the Dockerfile, not in the gitlab-ci itself. Same for mounting external directories: we need mounting (not a real requirement, but speeds up the build step) inside the docker build process. > But as everyone has said - one could toggle to another tool at a later > stage... if needed. > > > v2: > > - Review dependencies (Eric Anholt) > > - Install libdrm in base image with Meson (Eric Anholt) > > - Do system changes before apt to speed up installation (Daniel Stone) > > > > Signed-off-by: Juan A. Suarez Romero <jasua...@igalia.com> > > Acked-by: Daniel Stone <dani...@collabora.com> > > --- > > .gitlab-ci.yml | 177 ++++++++++++++++++++++++++++++++++++ > > gitlab-ci/Rockerfile.base | 185 ++++++++++++++++++++++++++++++++++++++ > > gitlab-ci/Rockerfile.llvm | 57 ++++++++++++ > > gitlab-ci/Rockerfile.mesa | 132 +++++++++++++++++++++++++++ > > 4 files changed, 551 insertions(+) > > create mode 100644 .gitlab-ci.yml > > create mode 100644 gitlab-ci/Rockerfile.base > > create mode 100644 gitlab-ci/Rockerfile.llvm > > create mode 100644 gitlab-ci/Rockerfile.mesa > > > > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml > > new file mode 100644 > > index 00000000000..5cee333dd45 > > --- /dev/null > > +++ b/.gitlab-ci.yml > > @@ -0,0 +1,177 @@ > > +image: docker:latest > > + > > +services: > > + - docker:dind > > + > > +stages: > > + - base > > + - llvm > > + - mesa > > + > > +variables: > > + DOCKER_IMAGE: $CI_REGISTRY_IMAGE > > + CCACHE_DIR: $CI_PROJECT_DIR/../ccache > > + LLVM: "6.0" > > + > > +cache: > > + paths: > > + - ccache/ > > + key: "$CI_JOB_STAGE" > > + > > +before_script: > > + - mkdir -p ccache > > + - rm -fr ../ccache > > + - mv ccache ../ > > nit: how does this look > rm -rf ../ccache > mkdir -p ../ccache > It wouldn't work. > Although why do we .. in the first place? Mind adding a comment? Yup. First of all, we cache the ccache directory in GitLab, so when re-building a Docker image we save time. GitLab only caches directories that are in the same path as the git clone/fetch is done. That is, it restores/saves directories that are in the same place as the full Mesa code. But we don't want to have the ccache there, because when building the image we add all the cloned content. And this would add inside the image the full ccache. We don't want this, but just mount it externally. Thus, we move the restored ccache to a different place at the beginning (the "mv ccache ../" in the before_script) and move back at the end so GitLab can store the new cache (the "mv ../ccache ./" in the after_script). As the very first time there is no ccache to restore, we ensure there's always a ccache directory (hence, the mkdir call). The "rmdir ../ccache" is to ensure there's nothing there before doing the move. I think this is a safe measure, as usually there shouldn't be nothing there. > > > + - export MAKEFLAGS=-j$(nproc) > > + - apk --no-cache add libc6-compat > > + - wget > > https://github.com/grammarly/rocker/releases/download/1.3.1/rocker-1.3.1-linux_amd64.tar.gz > > + - tar xvf rocker-1.3.1-linux_amd64.tar.gz > > + - rm rocker-1.3.1-linux_amd64.tar.gz > > + - mv rocker .. > > + - docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN $CI_REGISTRY > > + > > +after_script: > > + - mv ../ccache ./ > > + > > +.build_llvm: &build_llvm > > + stage: llvm > > + cache: {} > > + script: > > + - ../rocker build -f gitlab-ci/Rockerfile.llvm --var LLVM=$LLVM > > + - docker push $CI_REGISTRY_IMAGE:llvm-$LLVM > > + > > I think we can drop most, if not all the special LLVM handling. More > details below. > > > > + > > +llvm:3.3: > > + variables: > > + LLVM: "3.3" > > + <<: *build_llvm > > + > > +llvm:3.6: > > + variables: > > + LLVM: "3.6" > > + <<: *build_llvm > > + > > +llvm:3.8: > > + variables: > > + LLVM: "3.8" > > + <<: *build_llvm > > + > > I'm fairly sure we can drop anything older than 3.9 through the series. > Jose was pretty clear that they're aiming/moved to llvm 5.0 > I'm fine with this. We test so many versions because those are the minimum required versions according to configure.ac. If we think it is not needed to check older versions, we can remove them. On the other hand, we could just keep them when testing release branches, and remove when testing master. > > > +RUN apt-get update > > \ > > + && apt-get --no-install-recommends -y install autoconf automake gcc g++ > > libtool-bin \ > > + pkg-config gettext ccache make scons bison flex sudo git wget bzip2 > > xz-utils \ > > + libclc-dev libelf-dev libexpat1-dev libffi-dev libomxil-bellagio-dev > > \ > > + libpciaccess-dev libx11-xcb-dev libxdamage-dev libxml2-dev > > libxrender-dev \ > > + libxvmc-dev libunwind-dev zlib1g-dev python-pip python-setuptools > > python-wheel \ > > + python3-pip python3-setuptools python3-wheel > > \ > > + && rm -fr /var/lib/apt/lists/* > > Why do we need the rm after apt-get? > > This is suggested by Docker as ag ood pattern to install packages in Docker images. We update + install package + remove the files generated by the update everything in a single command, so we keep the Docker image size reduced to the minimum. > > +USER local > > + > > A user with name "local" sounds a bit strange. Is that the recommendation? We just picked "local" as username, but we're fine to use a different name (like "mesa" or "user"). Usually in Docker everything is done as "root". But in order to reduce risks, and be more real (developers never build Mesa as root, or shouldn't at least!) we build everything as non-root. > > > +WORKDIR /home/local > > + > > +ENV LDFLAGS="-L/usr/local/lib $LDFLAGS" > > + > > +{{ if .Env.MAKEFLAGS }} > > +ENV MAKEFLAGS={{ .Env.MAKEFLAGS }} > > +{{ end }} > > + > > +{{ if .Env.CCACHE_DIR }} > > +MOUNT {{ .Env.CCACHE_DIR }}:/home/local/.ccache:Z > > +RUN sudo chown -R local:local /home/local/.ccache > > +ENV PATH=/usr/lib/ccache:$PATH > > +{{ end }} > > + > > +ATTACH [ "/bin/bash" ] > > + > > +RUN wget > > https://xorg.freedesktop.org/releases/individual/proto/glproto-1.4.14.tar.bz2 > > \ > > + && tar -jxvf glproto-1.4.14.tar.bz2 > > \ > > + && rm glproto-1.4.14.tar.bz2 > > \ > > + && cd glproto-1.4.14 > > \ > > + && ./configure > > \ > > + && make > > \ > > + && sudo make install > > \ > > + && sudo ldconfig > > \ > > + && sudo rm -fr ../glproto-1.4.14 > > + > > Thinking out loud: > There should be a way to make this a trivial function and feed it the > static data. > ... > wget foo > tar filename(foo) > cd basename(foo) > ... > We couldn't figure out how to do it. Maybe there's a way to do loops inside the Rockerfiles. At this moment, this is very similar to what we do in .travis. > > > --- /dev/null > > +++ b/gitlab-ci/Rockerfile.llvm > > +{{ if eq .LLVM "3.3" }} > > +RUN wget > > https://people.igalia.com/jasuarez/packages/llvm-3.3_3.3-+checkinstall1_amd64.deb > > \ > > + && dpkg -i llvm-3.3_3.3-+checkinstall1_amd64.deb > > \ > > + && rm llvm-3.3_3.3-+checkinstall1_amd64.deb > > +ENV LD_LIBRARY_PATH=/usr/lib/llvm-{{ .LLVM }}/lib:$LD_LIBRARY_PATH > > + > > With 3.3 gone, there's no need to build our own LLVM package ;-) According to configure.ac, the minimum required LLVM version for Gallium drivers is 3.3. This is why we also use LLVM 3.6 and 3.8: to test the Gallium drivers. > > > +{{ else }} > > +MOUNT .:/context > > +RUN ./autogen.sh \ > > + && make distcheck \ > > + && __version=`cat VERSION` \ > > + && mkdir -p /context/release-output \ > > + && mv /home/local/mesa-head.txt /context/release-output \ > > + && mv mesa-$__version.tar.xz /context/release-output \ > > + && sudo rm -fr /home/local/mesa > > + > > +{{ else if eq .BUILD "autotools" "gallium" }} > > + > > +RUN export LLVM={{ $llvm_version }}.0\ > > + && eval `cat configure.ac | egrep ^LLVM_REQUIRED` > > \ > > + && if dpkg --compare-versions $LLVM ge $LLVM_REQUIRED_GALLIUM ; then > > GALLIUM_DRIVERS=i915,etnaviv,freedreno,imx,nouveau,pl111,r300,svga,swrast,tegra,v3d,vc4,virgl > > ; fi \ > > + && if dpkg --compare-versions $LLVM ge $LLVM_REQUIRED_R600 ; then > > GALLIUM_DRIVERS=$GALLIUM_DRIVERS,r600 ; fi \ > > + && if dpkg --compare-versions $LLVM ge $LLVM_REQUIRED_RADEONSI ; then > > GALLIUM_DRIVERS=$GALLIUM_DRIVERS,radeonsi ; fi \ > > + && if dpkg --compare-versions $LLVM ge $LLVM_REQUIRED_SWR ; then > > GALLIUM_DRIVERS=$GALLIUM_DRIVERS,swr ; fi \ > > /me dreams of a day where only a single LLVM_REQUIRED will be available > > > + && DRI_DRIVERS=i915,i965,nouveau,r200,radeon,swrast > > \ > > + && VULKAN_DRIVERS=intel > > \ > > + && if dpkg --compare-versions $LLVM ge $LLVM_REQUIRED_RADV ; then > > VULKAN_DRIVERS=$VULKAN_DRIVERS,radeon ; fi \ > > + && ./autogen.sh > > \ > > + --with-gallium-drivers=$GALLIUM_DRIVERS > > \ > > + {{ if eq .BUILD "gallium" }} --with-dri-drivers="" > > \ > > + {{ else }} --with-dri-drivers=$DRI_DRIVERS > > \ > > + --with-vulkan-drivers=$VULKAN_DRIVERS > > \ > > + --with-platforms=x11,drm,wayland {{ end }} > > \ > > Omitting a vulkan/dri/gallium drivers list will default to building > some of them :-\ Right. We need to add '--with-vulkan-drivers=""' when BUILD is gallium, as we are not interested in the Vulkan driver. > Perhaps we could set the *DRIVERS variables conditionally, defaulting to "". We are using three variables, GALLIUM_DRIVERS, DRI_DRIVERS and VULKAN_DRIVERS that are updated depending on BUILD and also the LLVM version. > > > > + {{ if ne $llvm_version "0.0" }} --enable-llvm > > --enable-llvm-shared-libs {{ end }} \ > > + {{ if ne $debug_build "false" }} --enable-debug {{ end }} > > \ > > + --enable-glx-tls --enable-gbm --enable-egl > > \ > > + && make > > \ > > + && make check > > \ > > + && sudo make install > > \ > > + && sudo ldconfig > > \ > > + && sudo rm -fr /home/local/mesa > > + > > +{{ else if eq .BUILD "meson" }} > > + > > +RUN meson _build \ > > Worth adding the gallium/vulkan/dri drivers list here? > Didn't add the list because this depends on the LLVM version we are using. So we trust meson correctly picks all the drivers. If we want to be explicit, maybe we can reuse the list of DRI_/VULKAN_/GALLIUM_DRIVERS here. > HTH > -Emil > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
