CI-Runner läuft manchmal nicht beim ersten Mal durch

Beispiel: https://git.thm.de/kim-team/tc-frontend/-/jobs/167722

Als die Pipeline automatisch angelaufen ist, lief der "build"-Job nicht durch, nachdem ich auf "Retry" gedrückt habe hat alles geklappt, lief aber relativ lang (8:36 min).

Fällt dir dazu was ein?

Update (22.09.19): Problem tritt immer noch auf, siehe https://git.thm.de/kim-team/tc-frontend/-/jobs/167932.

Update (23.09.19): Wir müssen das Problem mal strukturiert angehen. Ich würde gerne folgendes klären:

• Tritt das Problem nur auf, wenn vorher ein bestimmter anderer Job lief?
• Tritt das Problem nur auf bestimmten Runnern oder Runner-Versionen (11 oder 12?) auf?
• Haben manche Runner vlt. noch ein veraltetes Image?
• Ist es sinnvoll, ein paar ältere Runner abzuschalten und dafür zwei oder drei neue sauber aufzusetzen?
• Hat es evtl. etwas mit den Cache-Einstellungen in der .gitlab-ci.yml zu tun?
• Wie kriegen wir die Build-Zeiten runter? 8+ Minuten ist definitiv zu viel bei einem Runner in den Forks.
• Ist flutter build apk --release (noch) der richtige Befehl oder sollten wir eher App-Bundles bauen? Für Uploads im Play-Store wird das soweit ich weiß empfohlen.
• Muss die APK sowohl x86 als auch ARM unterstützen? Wenn wir nur eine Plattform ansprechen wird vlt. das Build schneller. Die erzeugte APK verwendet doch sowieso niemand, oder? Die ist nur dazu da, um zu schauen, ob das Build durchläuft, dachte ich.

Update (24.09.19): Ich hab die Heap-Size der JVM, die Gradle fürs Android-Build verwendet von variablen 1 bis 1,5 GB auf feste 512 MB gesenkt und ein paar kleinere Tweaks vorgenommen. Die Builds sollten jetzt nicht mehr den RAM des Servers überreizen und abstürzen. Des Weiteren habe ich in einem Artikel von einem CI-Dienstleister gelesen, dass Build-Zeiten in unserer Größenordnung bei Flutter-Projekten normal seien. Ich würde trotzdem gerne noch ausprobieren, ob man mit dem Cache und den Updates noch ein paar Sekunden rauskitzeln kann. Auch die Frage der Zielplattform würde ich gerne noch klären.

Update (02.10.19): Justin hatte nochmal von einem einzelnen Job berichtet, der fehlgeschlagen ist, seitdem ist das Problem aber nicht mehr aufgetaucht. Chris wollte außerdem bald einen neuen Server bereitstellen. Falls das Problem wieder auftritt, bitte wieder dieses Ticket aufmachen.

Update (08.10.19): Das Problem trat wieder auf, wurde aber nicht mehr näher untersucht. Bis auf Weiteres wird nur noch der neue Runner auf der Höllenkiste verwendet.