解读 CI 失败
Kibana CI 使用一种名为“管道”的 Buildkite 功能来自动测试拉取请求和跟踪分支中的代码。 管道在存储库中通过 .buildkite/pipelines
文件夹中的 Pipelines
定义。
有关 Buildkite 管道的更多信息,请参见文档。
当测试失败时,将通过 Github 检查报告给 Github。 目前,我们将测试分为几个类别,这些类别并行运行以加快 CI 速度。 像 ciGroup{{X}}
这样的组在 Github 中获得单个检查,而其他测试(如 linting 或类型检查)则获得自己的检查。
单击拉取请求对话选项卡中检查旁边的链接会将您带到该测试部分的日志输出。 如果该日志输出被截断,或者没有清楚地标识发生了什么,通常可以通过直接访问 Buildkite 来获得更完整的信息。
要在 Buildkite 中查看作业执行的结果,可以单击 @elasticmachine
留下的评论中的链接,或者在 PR 底部的列表中搜索 kibana-ci
检查。 此链接会将您带到失败的特定作业执行的顶层页面。
- Git 提交: 导致此构建的 git 提交。
- 测试结果: 指向测试结果屏幕的链接,以及指向失败测试的日志和作业的快捷方式。 功能测试捕获并存储来自每个特定测试的日志输出,并使它们在这些链接中可见。
- 管道步骤:: 已执行管道的分解,以及管道中每个步骤的单独日志输出。
管道步骤中的日志包含 Info
级别的日志记录。 要调试功能 UI 测试,通常查看调试日志很有帮助。 您可以通过单击 logs (1) 转到测试失败详细信息。
查看失败情况,我们首先查看错误和堆栈跟踪。 在下面的示例中,此测试未能找到超时内的元素; Error: retry.try timeout: TimeoutError: Waiting for element to be located By(css selector, [data-test-subj="createSpace"])
我们从堆栈跟踪中知道测试文件位于 test/accessibility/apps/spaces.ts
的第 50 行(此测试和堆栈跟踪上下文位于 kibana/x-pack/ 中,因此该文件是 https://github.com/elastic/kibana/blob/master/x-pack/test/accessibility/apps/group1/spaces.ts#L50)。 单击元素的函数是从 test/functional/page_objects/space_selector_page.ts
中的页面对象方法调用的 https://github.com/elastic/kibana/blob/master/x-pack/test/functional/page_objects/space_selector_page.ts#L58
[00:03:36] │ debg --- retry.try error: Waiting for element to be located By(css selector, [data-test-subj="createSpace"])
[00:03:36] │ Wait timed out after 10020ms
[00:03:36] │ info Taking screenshot "/dev/shm/workspace/parallel/24/kibana/x-pack/test/functional/screenshots/failure/Kibana spaces page meets a11y validations a11y test for click on create space page.png"
[00:03:37] │ info Current URL is: http://localhost:61241/app/home#/
[00:03:37] │ info Saving page source to: /dev/shm/workspace/parallel/24/kibana/x-pack/test/functional/failure_debug/html/Kibana spaces page meets a11y validations a11y test for click on create space page.html
[00:03:37] └- ✖ fail: Kibana spaces page meets a11y validations a11y test for click on create space page
[00:03:37] │ Error: retry.try timeout: TimeoutError: Waiting for element to be located By(css selector, [data-test-subj="createSpace"])
[00:03:37] │ Wait timed out after 10020ms
[00:03:37] │ at /dev/shm/workspace/parallel/24/kibana/node_modules/selenium-webdriver/lib/webdriver.js:842:17
[00:03:37] │ at runMicrotasks (<anonymous>)
[00:03:37] │ at processTicksAndRejections (internal/process/task_queues.js:93:5)
[00:03:37] │ at onFailure (/dev/shm/workspace/parallel/24/kibana/test/common/services/retry/retry_for_success.ts:17:9)
[00:03:37] │ at retryForSuccess (/dev/shm/workspace/parallel/24/kibana/test/common/services/retry/retry_for_success.ts:57:13)
[00:03:37] │ at Retry.try (/dev/shm/workspace/parallel/24/kibana/test/common/services/retry/retry.ts:32:14)
[00:03:37] │ at Proxy.clickByCssSelector (/dev/shm/workspace/parallel/24/kibana/test/functional/services/common/find.ts:420:7)
[00:03:37] │ at TestSubjects.click (/dev/shm/workspace/parallel/24/kibana/test/functional/services/common/test_subjects.ts:109:7)
[00:03:37] │ at SpaceSelectorPage.clickCreateSpace (test/functional/page_objects/space_selector_page.ts:59:7)
[00:03:37] │ at Context.<anonymous> (test/accessibility/apps/spaces.ts:50:7)
[00:03:37] │ at Object.apply (/dev/shm/workspace/parallel/24/kibana/node_modules/@kbn/test/src/functional_test_runner/lib/mocha/wrap_function.js:73:16)
但我们不知道测试为什么找不到该元素。 可能是它不在正确的页面上,或者该元素已更改。
在 ✖ fail:
行的正上方,有一行 info Taking screenshot ...
告诉我们要在 Google Cloud Storage (GCS) Upload Report: 中查找的屏幕截图的名称:
单击该 png 的 [Download]
链接会显示此图像
如果我们使用正在运行的 Kibana 实例并检查元素,我们会发现 createSpace
data-test-subj 属性位于 Stack Management 中的 Spaces 页面上的此按钮上
我们知道测试不在正确的页面上,无法找到要单击的元素。 我们在调试日志中看到重复尝试查找该元素。 如果我们滚动到那些重复尝试的开始,我们会看到测试所做的第一件事是尝试单击 createSpace
元素。
[00:01:30] └-> a11y test for manage spaces menu from top nav on Kibana home
[00:01:30] └-> a11y test for manage spaces page
[00:01:30] └-> a11y test for click on create space page
[00:01:30] └-> "before each" hook: global before each for "a11y test for click on create space page"
[00:01:30] │ debg TestSubjects.click(createSpace)
我们可以通过查看测试代码来确认这一点。
因此,我们需要回溯更远以找到测试打开 Spaces 页面的位置。 事实证明,此之前的测试会导航到正确的页面,但该测试被跳过(在 PR 中标记为 it.skip
)。
it.skip('a11y test for manage spaces page', async () => {
await PageObjects.spaceSelector.clickManageSpaces();
也许有人跳过了先前的测试,却没有意识到这些测试不是独立的。 最佳实践是每个测试都是原子的,并且不依赖于任何其他测试的结果。 但是在 UI 测试中,设置需要时间,并且我们通常需要为 describe 块中的测试组进行优化。