Beschleunigung des GH-Workflows: Nutzung der GH-Registry oder Bauen direkt auf dem Runner?

[cagix]

aus #16 (comment): ich hab grad noch ne andere (evtl. dumme) idee. im moment baue ich jedes mal im workflow ein neues docker-image und lasse die sachen dann in diesem container laufen. jonas hatte schon mal experimentiert, ob man zeit gewinnen würde, wenn man das image in der gh-registry ablegt und im workflow nur zieht - aber das hat nicht wirklich was gebracht (sagte er damals). wenn man die installationsskripte für die debian-pakete, die man beim erstellen des docker-images ausführt, direkt im ubuntu-runner ausführen würde und danach direkt im ubuntu-runner arbeiten würde, müsste das am ende doch schneller sein, oder? man spart sich das ziehen des basis-images und den overhead des dockerstarts für jeden befehl. was denkst du? lohnt es sich, hierfür nochmal ein ticket aufzumachen und da weiter zu experimentieren? oder ist das nur ne spinnerte idee, die am ende nicht viel bringt? oder sollte man eher nochmal der registry-sache nachgehen (eigentlich müsste das doch deutlich schneller sein als das image neu zu erstellen?!).

[liketechnik]

Allgemein

Ich weiß nicht wie die Makefile damit harmoniert ohne Docker Aufruf zu laufen (in beiden Fällen). Im Prinzip ist die ja schon geschrieben, um auch ohne Docker den Kram zu bauen. Aber ich kann mir vorstellen dass z. B. make dann fehlt, weil das ja im Container nie benötigt wurde.

Image (& Registry)

• GitHub bietet die Möglichkeit, die Jobs vom Workflow in einem Container auszuführen
• das Image in GitHub's Registry liegen zu haben könnte man nutzen, um das Image in ein separates Repo auszulagern, und nicht für alle Projekte einzeln verwalten. (Das "nicht neu bauen müssen" kann aber natürlich auch ein "generell genug halten müssen" und damit ein zusätzlicher, ungewollter Aufwand sein. Da sehe ich mich nicht in der Position, dass vernünftig abwägen zu können.)
• Wenn das Image in GitHub's Registry liegt könnte man sich das Image ziehen, statt lokal neu z bauen, und hat damit das Thema "X hat das Image das letzte mal vor 6 Monaten gebaut, seitdem ist aber z. B. Git geupdatet worden und geht jetzt bei Person Y, die jetzt neu gebaut hat, kaputt" zumindest seltener

Ohne Image

Jedes mal einen Container starten hat einen Overhead, ich habe aber keine Ahnung ob der nennenswert groß ist. Das Herunterladen vom Image vs. herunterladen der einzelnen Pakete + Installation sollte sich aber vmtl gegenseitig ausgleichen (wobei z. B. GitLab für die Runner Caches für häufig verwendete Distros hat, die dann im Zweifel schneller gehen. Aber eigtl sollte dann auch die Registry diesen Vorteil haben.)

Fazit

Ich würde zuerst tatsächlich die Registry + Image Sache nochmal ausprobieren, da sich hier auch weitere Vorteile ergeben könnten. Aber auch für den Weg ohne Image zu gehen halte ich ein Ausprobieren für sinnvoll.

[cagix]

das makefile läuft auch ohne container, es müssen halt die texlive-sachen da sein.

was halt interessant wäre: zeit für erzeugen und starten des containers vs. zeit für ziehen und starten des images aus der registry vs. installieren der pakete im runner ... die skripte zum installieren der packages im container sind debian-basiert und sollten direkt auch im ubuntu-runner lauffähig sein.

in einem parallelprojekt mit ähnlichem setup diskutiere ich tatsächlich grad die option, das ganze tooling in ein gemeinsames shared repo auszulagern. allerdings müsste man prüfen, ob msn das image in der gh-registry in der sichtbarkeit beschränken kann, um lizenzprobleme zu vermeiden.

[cagix]

ich schiebe das ticket mal ins pm-lecture-repo, weil ich dort die ganzen technischen sachen sammele und gemeinsam für pm+ki+cb bearbeite.

edit: ja super. ich kann nicht zwischen den organisationen springen :/

[cagix]

Das Thema wird in Programmiermethoden-CampusMinden/Prog2-Lecture#561 getrackt. Ich schließe das Ticket hier, damit es übersichtlich bleibt.