Cucumber-js: Kegagalan publikasi intermiten

Dibuat pada 21 Okt 2020  Β·  14Komentar  Β·  Sumber: cucumber/cucumber-js

Terlihat berikut ini sebentar-sebentar di CI:

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

Komentar yang paling membantu

Saya pikir itu layak untuk dicoba dengan --retry - senang menjalankannya dan melihat apa yang terjadi dengan misalnya 30 build berturut-turut?

Semua 14 komentar

Sejauh ini terlihat dua contoh ini di appveyor Node 10 dan satu contoh di travis Node 12

Terima kasih @charlierudolph kita akan melihat ini. cc @vincentcapicotto @vincent-psarga

Apakah ini masih menjadi masalah dengan 7.0.0 @charlierudolph?

Masih menjadi masalah dengan % build CI yang cukup tinggi.

@aurelien-reeves dan saya mencoba memperbaikinya beberapa bulan yang lalu tanpa hasil.

Saya pikir solusi pragmatis adalah dengan menonaktifkan tes ini untuk Windows di CI.

@aslakhellesoy apakah mereka pasti terbatas hanya untuk Windows?

Tidak, mereka tidak terbatas pada windows.
https://github.com/cucumber/cucumber-js/pull/1617 menunjukkan kepada kita bahwa semua build mungkin terpengaruh.
lihat https://github.com/cucumber/cucumber-js/commit/edc8f106edda0d001f1b31a82a5b4bd86f260fb5

Saya akan menyarankan:

  • menonaktifkan tes yang lembek

    • akhirnya mengeksekusi itu hanya ketika perubahan pada file tertentu didorong

  • jalankan kembali build setelah kegagalan pertama

Buruk saya - saya pikir itu hanya Windows.

Menjalankan ulang build tidak akan menyelesaikan apa pun, kemungkinan besar mereka akan gagal untuk kedua kalinya. Saya pikir kita akan memiliki peluang yang lebih baik dengan --retry . Tetapi bahkan kemudian itu mungkin berakhir gagal.

Kami membutuhkan uji coba yang konsisten 100%. Saya akan mengusulkan untuk menonaktifkan tes di CI. Kode ini memiliki churn yang rendah, dan mungkin cukup untuk menjalankannya secara lokal.

Buruk saya - saya pikir itu hanya Windows.

Menjalankan ulang build tidak akan menyelesaikan apa pun, kemungkinan besar mereka akan gagal untuk kedua kalinya. Saya pikir kita akan memiliki peluang yang lebih baik dengan --retry . Tetapi bahkan kemudian itu mungkin berakhir gagal.

Itulah yang ada dalam pikiran saya, menggunakan file rerun

Kami membutuhkan uji coba yang konsisten 100%. Saya akan mengusulkan untuk menonaktifkan tes di CI. Kode ini memiliki churn yang rendah, dan mungkin cukup untuk menjalankannya secara lokal.

Saya memiliki preferensi untuk yang itu juga

Sebagai informasi: build tampaknya lebih stabil dari sebelumnya.
Kegagalan baru-baru ini tidak selalu terkait dengan masalah itu, tetapi dengan audit ketergantungan. Tapi sepertinya sudah diperbaiki baru-baru ini.

Saya pikir itu layak untuk dicoba dengan --retry - senang menjalankannya dan melihat apa yang terjadi dengan misalnya 30 build berturut-turut?

Apakah tes ini benar-benar terintegrasi dengan server laporan mentimun hidup? Apakah mungkin untuk memanggil server rintisan sebagai gantinya, berjalan secara lokal? Atau menukar adaptor kecil yang membungkus panggilan ke titik akhir laporan jarak jauh?

Pengujian menggunakan server http Node lokal yang kami mulai dan hentikan di setiap pengujian.

Apakah halaman ini membantu?
0 / 5 - 0 peringkat