Cucumber-js: 间歇性发布失败

创建于 2020-10-21  ·  14评论  ·  资料来源: cucumber/cucumber-js

在 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

最有用的评论

我认为值得用--retry进行实验 - 很高兴运行它,看看连续构建 30 次会发生什么?

所有14条评论

到目前为止,在 appveyor Node 10 上看到了两个实例,在 travis Node 12 上看到了一个实例

谢谢@charlierudolph,我们会看看这个。 抄送@vincentcapicotto @vincent-psarga

这仍然是 7.0.0 @charlierudolph 的问题吗?

仍然是一个相当高百分比的 CI 构建的问题。

几个月前,@aurelien-reeves 和我试图解决这个问题,但没有成功。

我认为务实的解决方案是在 CI 中为 Windows 禁用这些测试。

@aslakhellesoy它们绝对仅限于 Windows 吗?

不,它们不仅限于窗户。
https://github.com/cucumber/cucumber-js/pull/1617向我们展示了所有构建都可能受到影响。
参见 https://github.com/cucumber/cucumber-js/commit/edc8f106edda0d001f1b31a82a5b4bd86f260fb5

我会建议:

  • 停用不稳定的测试

    • 最终仅在推送对特定文件的更改时执行那些

  • 第一次失败后重新运行构建

我的不好 - 我以为只有 Windows。

重新运行构建不会解决任何问题,它们很可能第二次失败。 我认为我们有更好的机会--retry 。 但即便如此,它也可能最终失败。

我们需要 100% 一致的测试运行。 我建议禁用 CI 中的测试。 此代码的流失率较低,在本地运行它们可能就足够了。

我的不好 - 我以为只有 Windows。

重新运行构建不会解决任何问题,它们很可能第二次失败。 我认为我们有更好的机会--retry 。 但即便如此,它也可能最终失败。

这就是我想到的,使用重新运行文件

我们需要 100% 一致的测试运行。 我建议禁用 CI 中的测试。 此代码的流失率较低,在本地运行它们可能就足够了。

我也偏爱那个

有关信息:构建似乎比以前更稳定。
最近的失败并不总是与这个问题有关,而是与依赖审计有关。 不过最近好像修好了。

我认为值得用--retry进行实验 - 很高兴运行它,看看连续构建 30 次会发生什么?

此测试是否真的与活黄瓜报告服务器集成? 是否可以让它在本地运行,而不是调用存根服务器? 或者换掉一个小适配器来包装对远程报告端点的调用?

该测试使用我们在每次测试中启动和停止的本地 Node http 服务器。

此页面是否有帮助?
0 / 5 - 0 等级

相关问题

edwinwright picture edwinwright  ·  3评论

lamartire picture lamartire  ·  6评论

nicojs picture nicojs  ·  3评论

igniteram picture igniteram  ·  7评论

dblooman picture dblooman  ·  7评论