Well, at least you are the first duck that would talk to me. đ
1 reply
Me, I am more of a GitHub guy, so any experiments with GitLab's CI may take me a while, but I have some experience with multiarch Docker builds.
1 reply
VĂt, maybe it's good to mention that we IoT are part of GitLab's Open Source Program, so we have more stuff available than the things from the free tier. :)
Ah it's worth mentioned that DH and IoT images were independent in the beginning. :)
2 replies
What happened to the original DH image maintainers?
IIRC Henri created the TeX Live DH account, and at almost the same time Ben came up the images to build our documentation. At some point, Henri saw potential in our images, and then we got the maintenance. :) I might ping hmenke to help me. :) Ben Frank is probably unavailable this weekend, I guess. :)
1 reply
I am a complete newbie with Docker images. To be honest, I think I tested a TeX Live image once for some reason. I don't even had a decent broadband. :)
I should stop talking with acronyms. :)
It's the first time one has approached us with a request for a new arch, so it's good for us as part of the learning process. :)
Just haven't used it much before. I mostly use various on-prem GitLabs. đ
I only know two sentences in Czech: ahoj and pivo prosim. :)
(Tom taught me :)
Tom told me the exact same thing. :) Hopefully I will be able to practice next year!
VĂt, again thank you so much for reaching out to us and raising awareness for more archs in the TeX Live image pool! Hopefully we will be able to generate those images! :)
Not a problem. It may not make sense to pursue this now if your pipelines are already full and your target audience are CI services, but I will dump what I know into the issue and we'll see. Worst-case scenario: we will have a pretty good tutorial for whoever wants to build their own texlive images on strange architectures.
Let's see how it goes. :) I always have a cheerful attitude. :)
3 replies
Without downloading the entire image and spawning a shell.
1 reply
One very efficient way of doing this is to have a Docker file that does
RUN tlmgr install scheme-minimal
RUN tlmgr install scheme-medium
...
RUN tlmgr install scheme-full
Because each of these is incremental you can just tag the individual layers and have perfect reuse.
Unfortunately this also means that build time for the Docker image will increase by a lot because
tlmgr is slow.
1 reply
Ben Frank: I've seen that but to be quite honest, I think this is unreasonable.
You just have to update the Debian base image once in a while.
3 replies
Otherwise you're distributing possibly insecure packages.
The only other solution I can think of would be to install TeX Live outside of the Docker container, then start
FROM scratch and copy the TeX Live tree inside. Then layer the Debian image on top of that.
Also users can just run
tlmgr update inside of their local copy.
1 reply
--- a/Dockerfile.latest
+++ b/Dockerfile.latest
@@ -45,7 +45,7 @@ RUN echo "Building with documentation: $DOCFILES" && \
# actually install TeX Live
cd install-tl* && \
# choose complete installation
- echo "selected_scheme scheme-full" > install.profile && \
+ echo "selected_scheme scheme-infraonly" > install.profile && \
# ⌠but disable documentation and source files when asked to stay slim
if [ "$DOCFILES" = "no" ]; then echo "tlpdbopt_install_docfiles 0" >> install.profile && \
echo "BUILD: Disabling documentation files"; fi && \
@@ -60,6 +60,12 @@ RUN echo "Building with documentation: $DOCFILES" && \
# add all relevant binaries to the PATH
$(find /usr/local/texlive -name tlmgr) path add
+RUN tlmgr install scheme-minimal
+RUN tlmgr install scheme-basic
+RUN tlmgr install scheme-small
+RUN tlmgr install scheme-medium
+RUN tlmgr install scheme-full
+
RUN \
# test the installation
latex --version && printf '\n' && \
This is what I have in mind.
1 reply
The schemes
context, gust, and tetex can be ignored I think.
The
scheme-gust is specific to GUST I guess and users of ConTeXt are anyway much better off using the ConTeXt beta images.
tetex doesn't exist anymore (it was the predecessor of TeX Live) but if necessary this scheme would go between medium and full.
Hello. When can we expect TL2021-historic images on GitLab and DockerHub?
1 reply
I see. That's an annoyance to be sure! Have you tried passing --force-rm and --no-build-cache to docker build?
1 reply
It makes
docker build more aggressive about the layers it keeps when building. Please, let me know if it helps. đ
Unfortunately, it does not work. GL runners are simply not suited anymore. I now built the image locally and will push it from here. But only for
TL2021-historic (no doc, no src).