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)
Bisher wurden zwei Instanzen davon auf Appveyor Node 10 und eine Instanz auf travis Node 12 gesehen
Ein weiterer auf Appveyor Node 12
https://ci.appveyor.com/project/charlierudolph/cucumber-js/builds/35868261/job/7lrpwx471aemhe4y
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:
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.
Hilfreichster Kommentar
Ich denke, es könnte sich lohnen, mit
--retry
zu experimentieren.