Ember.js: [2.15.0] – Ember baut Speicherfehler auf, während CI-Tools verwendet werden

Es scheint, dass es einige Leute gibt, die Karma-Tests haben, die mit diesem Schritt arbeiten:

https://discuss.circleci.com/t/running-browser-tests/10998/9

Nach den letzten Stunden konnte ich dies noch nicht erfolgreich zum Laufen bringen, aber ich bin ziemlich zuversichtlich, dass dies nicht speziell ember.js ist .... Schließt vorerst.

Ich habe das gleiche Problem und konnte es nicht lösen.

Ich habe mich am Wochenende ein wenig mit @mwisner und @kiwiup darüber unterhalten und wir haben herausgefunden, dass es mit der neuen Parallelität zu tun hat, die zu broccoli-babel-transpiler hinzugefügt wurde. Es wird standardmäßig auf die Anzahl der derzeit vorhandenen CPUs parallelisiert. Leider zeigt dies auf CircleCI 36 CPUs an, aber der Job selbst ist auf 2 gleichzeitige Prozesse beschränkt (und auch im verfügbaren RAM begrenzt).

Die Lösung hier besteht darin, die Umgebungsvariable JOBS auf 1 zu setzen, um die Parallelität auf CI im Wesentlichen zu deaktivieren.

@rwjblue danke für den Kontext hier!

Selbst mit der Parallelität von Circle würde ich denken (weil sie in Container aufgeteilt sind), dass JOBS dann immer 1 sein müsste. Also durch...

um die Parallelität auf CI im Wesentlichen zu deaktivieren

... Ich gehe davon aus, dass Sie die Broccoli-Babel-Transpiler-Parallelität und nicht die Container-Parallelität von Circle deaktivieren möchten. Ist das richtig?

@eric-hu scheint dir das auch eine korrekte Lektüre zu sein? Ist dies etwas, von dem wir erwarten sollten, dass es von Circle behoben wird, damit die tatsächlich im Job verfügbaren CPUs angezeigt werden? Verhindert dies jede Art von Parallelität auf der Seite von Circle (durch Aufteilen von Tests mit etwas wie ember-exam zum Beispiel)?

Ich bin mir nicht sicher, ob wir selbst ein Fix-Formular erwarten können ... Ich bin nicht super 100%, aber ich denke, es ist eher ein Docker-Problem als ein spezielles Kreisproblem. Oder vielleicht ein Node + Docker-Problem, das die vom Docker-Container auferlegten CPU-/Speicherbeschränkungen nicht genau erkennen kann.

Ich habe dieses Repo zu Experimentierzwecken erstellt: https://github.com/mwisner/ember-circleci-example.

Es enthält Circleci 2.0 (funktioniert mit der von @rwjblue bereitgestellten JOBS=1-Problemumgehung) (https://github.com/mwisner/ember-circleci-example/blob/master/.circleci/config.yml)

Zusammen mit den öffentlichen Zirkelaufbauten: https://circleci.com/gh/mwisner/ember-circleci-example/83

Ich habe das Repo jedoch auch zu Travis ci hinzugefügt, das auch Docker für Builds verwendet. Ich habe die Travis-Konfigurationsdatei noch nicht repariert, aber Sie können sehen, dass die Travis-Builds mit der bereitgestellten Travis-Konfiguration fehlschlagen (https://travis- ci.org/mwisner/ember-circleci-example/builds)

Danke @mwisner. Habe ich richtig gedacht, dass JOBS=1 _nicht_ bedeutet, dass wir die Builds selbst nicht parallelisieren können?

@JoshSmith Ja, wenn ich das richtig verstehe, soll die Parallelität im Broccoli-Babel-Transpiler deaktiviert werden. Sich nicht umkreisen. Theoretisch wäre also die Verwendung von circleci parallelism + jobs=1 in Ordnung?

Aber ich persönlich habe nicht mit der Verwendung der Parallelitätsfunktion von circleci experimentiert. Ich bin mir also nicht 100% sicher, wie eine Konfigurationsdatei dafür aussehen würde.

Macht Sinn! Ich wollte sichergehen, dass ich hier nur eine klare Linie zwischen scheinbar zwei unterschiedlichen Verwendungen von „Parallelität“ ziehe, also denke ich, dass ich endlich auf derselben Seite bin.

Mir ist aufgefallen, dass Sie JOBS=1 manuell in der Konfiguration vor ember test eingestellt haben, aber es scheint, als könnte dies auf der ENV-Variablenebene in Circle eingestellt werden, vielleicht ohne Probleme?

Es ist auch nicht spezifisch für Tests. Das OOM-Problem wird während der Build-Phase des Ember-Tests verursacht. Ich habe auch nur ember build mit dem gleichen OOM-Ergebnis getestet.

@JoshSmith Ich glaube, dass das Festlegen von JOBS = 1 auf der Ebene der Umgebungsvariablen ebenfalls funktionieren würde, aber ich habe es nicht bestätigt.

Mir ist aufgefallen, dass es ein Muster zum Festlegen von env-Variablen für Ember-CLI-Befehle für einige Add-Ons gibt:

https://github.com/ember-cli/broccoli-viz#usage
https://github.com/kategengler/ember-cli-code-coverage#usage

Also ging ich einfach von diesen Nutzungsmustern aus.

Ohne _irgendetwas_ darüber zu wissen, wie broccoli-babel-transpiler tatsächlich funktioniert, ist es für mich schwer zu sagen, ob Circle (oder Docker oder wer auch immer) eine Lösung dafür bereitstellen könnte oder nicht. Das _Gefühl_ meines Laien – nicht Nachdenken – wäre, dass wir hier vielleicht das Problem der reinen Inferenz vermeiden könnten, wenn der Transpiler explizite Anweisungen dazu entgegennehmen könnte, wie viele Kerne verfügbar sind. Auch dies kommt von einem Ort tiefer Unwissenheit.

Nur zur Aktualisierung kann ich diese Builds erfolgreich ausführen, wenn JOBS $ in den Umgebungseinstellungen von Circle auf 1 gesetzt ist. Nochmals vielen Dank @rwjblue , @mwisner und @eric-hu.

Ich bin gerade auf dasselbe Problem auf CircleCI gestoßen, und JOBS=1 hat es auch für mich behoben, danke an alle :v:

@eric-hu scheint dir das auch eine korrekte Lektüre zu sein? Ist dies etwas, von dem wir erwarten sollten, dass es von Circle behoben wird, damit die tatsächlich im Job verfügbaren CPUs angezeigt werden? Verhindert dies jede Art von Parallelität auf der Seite von Circle (durch Aufteilen von Tests mit so etwas wie Ember-Exam zum Beispiel)?

@JoshSmith Für CircleCI 2.0 sind zwei Parallelitätskonzepte zu beachten:

A. Parallelität pro Befehl, begrenzt auf die Anzahl der Kerne, die einer Containergruppe zur Verfügung stehen. Standardmäßig werden jeder Containergruppe 2 CPU-Anteile zugewiesen, was garantiert, dass sie 2 CPU-Kerne erhält. Es gibt eine Premium-Funktion für konfigurierbare Ressourcen, mit der Sie einen größeren/kleineren Anteil auswählen können (1, 4, 8 von oben nach unten).

B. CircleCI-Parallelität, die Sie sich vorstellen können als „auf wie viele Maschinen [1] möchte ich das verteilen?“. Dies ist nützlich für die Testisolierung, wenn Sie möglicherweise zwei Tests gleichzeitig ausführen und beide in eine Datenbank schreiben möchten. Dies ist beispielsweise weniger nützlich, um Ihre Assets zu transpilieren; Wahrscheinlich möchten Sie, dass alle Ihre Tests mit den transpilierten Assets ausgeführt werden.

Zu A: Da Sie standardmäßig 2 Kerne garantiert zur Verfügung haben, können Sie den gewünschten Befehl möglicherweise mit JOBS=2 ausführen. Dies kann die Ausführung beschleunigen, aber ich habe nicht überprüft, ob es funktioniert.

Bezüglich B: Selbst mit JOBS=1 können Sie immer noch CircleCI-Parallelität verwenden, um Ihre Testsuite zu beschleunigen.

In Bezug auf „Wer sollte das beheben?“ habe ich dies als ein lang andauerndes Problem mit mehreren Containerisierungstools gesehen. Die Containerisierungstools CircleCI 2.0 und 1.0 – Docker bzw. LXC – lecken Informationen über das Hostsystem für viele gängige Linux-Befehle, wie z. B. diejenigen, die verwendet werden, um zu prüfen, wie viele Kerne verfügbar sind. Das ist schon seit einigen Jahren so, ich denke, wenn es eine einfache Lösung gäbe, wäre es jetzt gelöst. Um die Sache noch komplizierter zu machen, änderte CircleCI das CPU-Kern-Verfügbarkeitsmodell von 1.0 auf 2.0. In 1.0 bekamen Sie eine feste Anzahl von Kernen für einen Job. In 2.0 werden Ihnen CPU-Anteile zugewiesen, um Ihre Mindestanzahl an Kernen zu garantieren. Wenn Sie sich auf einem voll ausgelasteten Host befinden, erhalten Sie mindestens so viele Kerne. Wenn Sie auf einem nicht ausgelasteten Host arbeiten, stehen Ihnen mehr Kerne zur Verfügung. Tools wie broccoli-babel-transpiler neigen jedoch dazu, die Anzahl der verwendeten Kerne nur einmal zuzuweisen, und die verfügbaren Ressourcen können sich während der Lebensdauer des Programms ändern. Am besten codieren Sie Ihre CI-Skripts einfach fest, um die garantierten verfügbaren Ressourcen zu verwenden.

[1] Ihr Code wird möglicherweise nicht auf N-Computern für N-Parallelität ausgeführt. Aber Sie können es sich so vorstellen, da sie effektiv voneinander isoliert sind.

Ich habe gerade JOBS=2 in meiner App ausprobiert und der Build war ebenfalls erfolgreich. Sollte das hier der kanonische Rat sein?

Kein merklicher Zeitunterschied zwischen diesen Werten in meiner kleinen Beispiel-FWIW.

@rwjblue Ich weiß, dass Sie empfohlen haben, dieses Problem im Ember-Cli-Repo zu haben. Ich habe dieses Problem jedoch geöffnet, als ich das Problem zum ersten Mal entdeckte, und es sieht so aus, als ob es gefunden wurde, bevor ich ein weiteres im Ember-Cli-Repo öffnen konnte ... Möchten Sie, dass ich dort ein weiteres Problem eröffne und nur auf diese Konversation verweise? Wissen Sie trotzdem, wie Sie es leicht verschieben können?

Ich habe dieses Problem erneut geöffnet, da nach einigen zusätzlichen Tests die bereitgestellte travisci.yml-Konfiguration, die mit Ember geliefert wird, ebenfalls auf dieses Problem stößt.

Obwohl ich verstehe, dass Ember Circle nicht unterstützt, denke ich, dass es schön wäre, wenn das Problem zumindest in der mitgelieferten travisci.yml-Datei behoben wäre.

Ich habe auch den Titel und die Beschreibung aktualisiert, um sie ein wenig allgemeiner zu gestalten und nicht speziell auf circleCI zu beziehen

@eric-hu vielen Dank für die ausführliche Beratung hier. Sehr hilfreich für die Community, um zu verstehen, was im Detail vor sich geht. Es wäre großartig, ein kanonisches Beispiel pro Framework in der Dokumentation zu sehen, obwohl ich die Zeit verstehe und schätze, die dies in Anspruch nehmen würde.

@bgentry danke für die Berichterstattung über den Zeitunterschied. Ich hatte gehofft, dass es die Bauzeiten beschleunigen würde. Ich werde auch JOBS=2 setzen, bin aber etwas enttäuscht darüber, da meine Build-Zeiten bei weitem mein größtes Hindernis bei der Beschleunigung von Circle-Jobs sind.

oh wow, ich bin froh, dass ich endlich diese Konversation gefunden habe, denn das ist mir auch passiert. Ich wusste zunächst nicht, wonach ich suchen sollte, weil npm test für mich auf Travis das Zeitlimit überschritten hatte, ohne Rückmeldung. Erst als ich versuchte, Timeouts zu überschreiben (was Sie normalerweise dem Support schreiben müssten), bekam ich eine ENOMEM , was mich schließlich hierher führte.

Der Wechsel zu JOBS=2 npm test hat dazu geführt, dass meine Builds erneut bestanden wurden (oder zumindest aus den richtigen Gründen fehlgeschlagen sind 😆), also danke an alle!

Vielleicht ist mir das nur auf Travis passiert, weil die Anwendung starke Abhängigkeiten hat, aber es war schwierig zu debuggen und ich habe es lange Zeit einfach ignoriert, also scheint es eine Überlegung wert zu sein, wie man damit im Ember-CLI-Blueprint oder anderweitig umgeht es.

In meinen Tests läuft ein Standard-Out-of-the-Box-Ember-Projekt ohne Änderungen einwandfrei, die Einführung einer Reihe von Abhängigkeiten verursacht letztendlich den Fehler.

Ich bin mir nicht sicher, was in einem Ember-Projekt als "viele" Abhängigkeiten angesehen wird. Aber da Travis der De-facto-Weg ist, CI mit Ember-Addons zu machen, denke ich, dass die Leute dies immer mehr sehen werden, wenn die Leute anfangen zu aktualisieren / neue Addons zu erstellen.

Ich habe vor kurzem damit begonnen, alle Abhängigkeiten für das Ember-Burger-Menü-Projekt zu aktualisieren, und erhalte diesen Fehler.
Beispiel:
https://travis-ci.org/offirgolan/ember-burger-menu/builds/275031562?utm_source=github_status&utm_medium=notification
https://github.com/offirgolan/ember-burger-menu/pull/95

Oh! Vielen Dank @mwisner für das Posten dieses Problems und @rwjblue für die vorübergehende Lösung! Ich habe nur ein paar Stunden damit verbracht zu verstehen, warum meine Builds fehlschlagen. Das Setzen von JOBS auf 1 reicht aus 🎉

Das Schließen als JOBS=1 wurde vor einiger Zeit als Standard in Ember-Cli aktualisiert. Entschuldigung für die Probleme...

Ich musste nur JOBS=1 hinzufügen, um dieses Problem auf 3.16.0 zu beheben. Gab es einen Rückfall?