-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Beschleunigung des GH-Workflows: Nutzung der GH-Registry oder Bauen direkt auf dem Runner? #24
Comments
AllgemeinIch 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)
Ohne ImageJedes 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.) FazitIch 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. |
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. |
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 :/ |
Das Thema wird in Programmiermethoden-CampusMinden/Prog2-Lecture#561 getrackt. Ich schließe das Ticket hier, damit es übersichtlich bleibt. |
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?!).
The text was updated successfully, but these errors were encountered: