Cucumber-js: Zeitweilige Veröffentlichungsfehler

Erstellt am 21. Okt. 2020  ·  14Kommentare  ·  Quelle: cucumber/cucumber-js

Folgendes zeitweise auf CI gesehen:

1) Scenario: the publication banner is not shown when publication is done # features\publish.feature:114
   √ Before # features\support\hooks.ts:16
   √ Before # features\support\hooks.ts:20
   √ Given a report server is running on 'http://localhost:9987' # features\step_definitions\report_server_steps.ts:8
   √ And my env includes "CUCUMBER_PUBLISH_URL=http://localhost:9987/api/reports" # features\step_definitions\cli_steps.ts:15
   √ And a file named "features/a.feature" with: # features\step_definitions\file_steps.ts:10
       """
       Feature: a feature
         Scenario: a scenario
           Given a step
       """
   √ And a file named "features/step_definitions/steps.js" with: # features\step_definitions\file_steps.ts:10
       """
       const {Given} = require('@cucumber/cucumber')
       Given(/^a step$/, function() {})
       """
   √ When I run cucumber-js with arguments `--publish` and env `` # features\step_definitions\cli_steps.ts:29
   √ Then the error output does not contain the text: # features\step_definitions\cli_steps.ts:118
       """
       Share your Cucumber Report with your team at https://reports.cucumber.io
       """
   √ After # features\support\hooks.ts:110
   × After # features\support\hooks.ts:97
       Error: Last run errored unexpectedly. Output:
       .
       1 scenario (1 passed)
       1 step (1 passed)
       0m00.005s (executing steps: 0m00.000s)
       Error Output:
       ┌──────────────────────────────────────────────────────────────────────────┐
       │ View your Cucumber Report at:                                            │
       │ https://reports.cucumber.io/reports/f318d9ec-5a3d-4727-adec-bd7b69e2edd3 │
       │                                                                          │
       │ This report will self-destruct in 24h unless it is claimed or deleted.   │
       └──────────────────────────────────────────────────────────────────────────┘
       events.js:174
             throw er; // Unhandled 'error' event
             ^
       Error [ERR_STREAM_PREMATURE_CLOSE]: Premature close
           at ClientRequest.onclose (internal/streams/end-of-stream.js:57:15)
           at ClientRequest.emit (events.js:203:15)
           at Socket.socketCloseListener (_http_client.js:358:9)
           at Socket.emit (events.js:203:15)
           at TCP._handle.close (net.js:607:12)
       Emitted 'error' event at:
           at errorOrDestroy (internal/streams/destroy.js:107:12)
           at stream._final (_stream_writable.js:620:7)
           at sendRequest (C:\projects\cucumber-js\lib\formatter\http_stream.js:49:28)
           at stream_1.pipeline (C:\projects\cucumber-js\lib\formatter\http_stream.js:102:21)
           at internal/streams/pipeline.js:84:7
           at internal/util.js:370:14
           at ClientRequest.eos (internal/streams/pipeline.js:33:21)
           at ClientRequest.<anonymous> (internal/util.js:370:14)
           at ClientRequest.onclose (internal/streams/end-of-stream.js:58:23)
           at ClientRequest.emit (events.js:203:15)
           [... lines matching original stack trace ...]
           at TCP._handle.close (net.js:607:12)
           at World.<anonymous> (C:\projects\cucumber-js\features\support\hooks.ts:103:11)
incomplete bug build

Hilfreichster Kommentar

Ich denke, es könnte sich lohnen, mit --retry zu experimentieren.

Alle 14 Kommentare

Bisher wurden zwei Instanzen davon auf Appveyor Node 10 und eine Instanz auf travis Node 12 gesehen

Danke @charlierudolph wir werden uns das anschauen. cc @vincentcapicotto @vincent-psarga

Ist dies immer noch ein Problem mit 7.0.0 @charlierudolph?

Immer noch ein Problem mit einem ziemlich hohen Prozentsatz von CI-Builds.

@aurelien-reeves und ich haben vor einigen Monaten erfolglos versucht, dies zu beheben.

Ich denke, die pragmatische Lösung besteht darin, diese Tests für Windows in CI einfach zu deaktivieren.

@aslakhellesoy sind sie definitiv auf Windows beschränkt?

Nein, sie sind nicht auf Fenster beschränkt.
https://github.com/cucumber/cucumber-js/pull/1617 zeigt uns, dass alle Builds betroffen sein können.
Vgl. https://github.com/cucumber/cucumber-js/commit/edc8f106edda0d001f1b31a82a5b4bd86f260fb5

Ich würde vorschlagen:

  • Deaktivieren der Tests, die flacky sind

    • diese werden schließlich nur ausgeführt, wenn Änderungen an bestimmten Dateien gepusht werden

  • Build nach einem ersten Fehler erneut ausführen

Mein Fehler - ich dachte, es wäre nur Windows.

Das erneute Ausführen des Builds wird nichts lösen, es ist genauso wahrscheinlich, dass sie ein zweites Mal fehlschlagen. Ich denke, wir hätten mit --retry bessere Chancen. Aber selbst dann kann es am Ende scheitern.

Wir brauchen 100 % konsistente Testläufe. Ich würde vorschlagen, die Tests in CI zu deaktivieren. Dieser Code weist eine geringe Abwanderung auf, und es kann ausreichen, ihn lokal auszuführen.

Mein Fehler - ich dachte, es wäre nur Windows.

Das erneute Ausführen des Builds wird nichts lösen, es ist genauso wahrscheinlich, dass sie ein zweites Mal fehlschlagen. Ich denke, wir hätten mit --retry bessere Chancen. Aber selbst dann kann es am Ende scheitern.

Das hatte ich mir vorgestellt, mit der Wiederholungsdatei

Wir brauchen 100 % konsistente Testläufe. Ich würde vorschlagen, die Tests in CI zu deaktivieren. Dieser Code weist eine geringe Abwanderung auf, und es kann ausreichen, ihn lokal auszuführen.

Da habe ich auch eine Vorliebe

Zur Information: Der Build scheint stabiler zu sein als früher.
Die jüngsten Ausfälle standen nicht immer im Zusammenhang mit diesem Problem, sondern mit Abhängigkeitsprüfungen. Aber es scheint vor kurzem behoben worden zu sein.

Ich denke, es könnte sich lohnen, mit --retry zu experimentieren.

Ist dieser Test tatsächlich in den Live-Gurkenberichtsserver integriert? Wäre es möglich, stattdessen einen Stub-Server aufzurufen, der lokal ausgeführt wird? Oder einen kleinen Adapter austauschen, der die Anrufe an die Endpunkte der Remote-Berichte umschließt?

Der Test verwendet einen lokalen Node-HTTP-Server, den wir in jedem Test starten und stoppen.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen