Gladys v4.0.5 erstellen

Entwicklung
21

Okay, ich habe den Build abgebrochen, die Abhängigkeiten der Dienste waren nicht installiert, weil die für den Build auf GitHub Actions verwendete Architektur nicht mit den kompatiblen Architekturen der Dienste übereinstimmt:

Screenshot 2021-02-03 at 19.38.35
Screenshot 2021-02-03 at 19.38.352146×586 75.8 KB

Offensichtlich ist s390x eine IBM-Architektur…

Ich habe @VonOx überprüft, der Fehler war auch in deinen Builds, aber er ist ein bisschen untergegangen, weil die Installation der Dienstabhängigkeiten nicht blockierend für die Installation von Gladys ist…

Vielleicht sollten wir einen Flag setzen, wenn wir auf CI bauen, damit es abstürzt, falls die Abhängigkeiten nicht erfolgreich installiert werden, das wäre cool :sweat_smile:

22

Ja, ich hatte alles, was « buildbar » war, mit dem Basis-Image node:12 gepusht.

Ja, s390 ist nicht üblich.

Ich bin mir nicht sicher, ob wir bei Circle den Flow bei einem Fehler in den Diensten stoppen.

Ist das wirklich ein Problem mit den Abhängigkeiten oder liegt es einfach daran, dass die Plattform nicht im package.json vorhanden ist?

23

Nein, nein, das haben wir nicht gemacht, das war eher eine allgemeine Bemerkung!

Nein, nur die Plattform steht nicht in der package.json, nichts Ernstes.

24

Außerdem, da es nicht Docker ist, das den Fehler zurückgibt, sondern npm über qemu/docker, denke ich, dass es unmöglich ist, dies abzufangen.

Man müsste es mit dem Installationsskript der Dienste abfangen und die Info irgendwie an den übergeordneten Prozess weiterleiten. :thinking:

25

Der Installationsprozess ist hausgemacht, das ist ein Skript, das ich selbst geschrieben habe.

Man muss nur das Skript zum Absturz bringen (derzeit ist es ein stummer Fehler).

26

Also als Quick-Fix habe ich linux/s390x aus dem Build entfernt, ich denke nicht, dass es sich lohnt, Zeit in den Build für IBM-Architektur zu investieren :slight_smile:

Falls jemand das wirklich braucht, werden wir weitere Tests durchführen und es hinzufügen, aber jetzt gibt es wichtige Fixes, die in die Produktion müssen!

27

Die hatte ich gar nicht gesehen :sweat_smile:

28

@VonOx Build v4.0.7 gestartet. Drücken wir die Daumen!

29

Alles klar, Gladys v4.0.7 ist live! Alles scheint auf meiner Seite gut zu sein :slight_smile:

30

Dann sollte es normalerweise automatisch sein, also sollte ich über 4.0.4 sein, oder? Denn ich bin bei 4.0.4 auf meiner Produktionsinstanz.

31

Man springt von der 4.0.4 zur 4.0.7 (wegen Tests/Fixes im CI).

32

Da hab ich mir doch gleich gedacht, dass ich die Frage stellen sollte :slight_smile:

33

Ich habe mir dieselbe Frage gestellt! Gibt es eine Notiz zur Veröffentlichung?

34

@Goulby Ich warte immer ein bisschen, bevor ich einen offiziellen Post mache, damit sich die Veröffentlichung etwas verbreiten kann und ich Feedback zu verschiedenen Architekturen bekomme.

Ich werde wie gewohnt einen Post in Actualités heute veröffentlichen :slight_smile:

35

Okay, danke! Dann denke ich, dass ich auf GitHub nachschauen kann, was hinzugefügt wurde.

36

Du nimmst, was seit der 4.0.4 (8. Januar) commited wurde.

37

Wenn von der Version die Rede ist, denke ich, dass man nicht zögern sollte, die Nebenversion 4.1.0 zu erhöhen, wenn es eine oder mehrere neue Funktionen gibt. Das folgt dem Prinzip von Semantic Versioning.

38

@cicoub13 Ich zögere, bei Gladys Semantic Versioning zu verwenden, weil es bei jeder Veröffentlichung neue Funktionen gibt. Wenn ich das strikt befolgen würde, müsste ich bei jeder Veröffentlichung eine Minor-Version machen.

39

Oder irgendetwas dazwischen, bei jedem neuen Service, oder?

40

@Goulby :

@VonOx : mal sehen, in diesem Fall könnte man auch gleich auf SemVer verzichten :slight_smile: