<div dir="ltr"><div class="gmail_default" style="font-family:times new roman,serif">I could probably provide the computing power, we can discuss this in private.</div><div class="gmail_default" style="font-family:times new roman,serif"><br></div><div class="gmail_default" style="font-family:times new roman,serif">Uwe</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Do., 12. Mai 2022 um 12:38 Uhr schrieb Paulo Roberto Massa Cereda <<a href="mailto:cereda.paulo@gmail.com">cereda.paulo@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi list,<br>
<br>
For a few years, we have been providing the more or less official TL <br>
docker images at <a href="https://hub.docker.com/r/texlive/texlive" rel="noreferrer" target="_blank">https://hub.docker.com/r/texlive/texlive</a> (repository at <br>
<a href="https://gitlab.com/islandoftex/images/texlive" rel="noreferrer" target="_blank">https://gitlab.com/islandoftex/images/texlive</a>). This especially includes <br>
the latest TeX Live from net installer (in four flavors: no src/no doc <br>
tree, with src/no doc tree, no src/with doc tree, with src/with doc <br>
tree) and historic images (i.e. from previous years' final ISO images).<br>
<br>
Up to now, all these images and flavors have been built using GitLab CI <br>
which was very easy to set up and use for us. However, as of this year, <br>
TL has grown to a size where the GitLab provided capacities does not <br>
allow us to build the latest TL image with src/with doc tree anymore. <br>
And for historic images it even fails to build the barebones ones even <br>
for as small ones as TL 2014.<br>
<br>
There are two properties of the GitLab runners that fail here:<br>
<br>
- The CI runners have a job timeout of 3 hours. Especially with historic <br>
images where only few mirrors are available we regularly get timeouts.<br>
<br>
- The CI runners are limited to approx. 20 GB of space. With all the <br>
Docker setup this starts to fail when images reach approx. 5 GiB of <br>
space which the `latest-doc-src` image (and actually the images with <br>
documentation and sources of previous years) are reaching.<br>
<br>
So here we are looking for alternatives to continue providing these <br>
images. Our Dockerfiles are fully functional, so it is really only a <br>
matter of build capacity. We are open to all alternatives. The essential <br>
two alternatives we have thought of:<br>
<br>
- setting up an own GitLab CI runner on some hardware (which hardware?)<br>
- build somewhere else (some server or GitHub actions or something that <br>
copes with the large images).<br>
<br>
Essentially, what we need either way is longer job timeouts and more <br>
available disk space (approx. 30–40 GB of free space for building). RAM <br>
and network bandwidth are actually not a bottleneck because in this kind <br>
of setup, we are mostly limited by the mirrors and TL installation is <br>
primarily disk I/O-heavy.<br>
<br>
For both options outlined above we lack capacities. So we are looking <br>
for help on that or advise on other options.<br>
<br>
Just to have it mentioned somewhere: Until we have found some kind of <br>
replacement, we cannot continue providing all image flavors.<br>
<br>
If anyone has ideas how we can continue providing all Docker images or <br>
would be willing to help us implement a new build infrastructure, we are <br>
eagerly waiting for ideas.<br>
<br>
Greetings from the island!<br>
<br>
Cheerio,<br>
<br>
Paulo<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Dr. Uwe Ziegenhagen</div><div>0179-7476050<br><<a href="http://www.uweziegenhagen.de" target="_blank">http://www.uweziegenhagen.de</a>></div></div></div>