* [QA][Code Coverage] Add a link to discover pinned to the current build.
When personnel other than myself wish to visually verify code coverage,
this link will be available in the ci output.
* Drop single quotes.
* Add annotation per J Budz.
* Fixup text.
* Drop debug.
## Summary
Fixes issue with security solution cypress flaky test runner
After introducing [dynamic split for cypress tests in Security Solution](https://github.com/elastic/kibana/pull/125986), there was discovered an issue with flaky test runner, which is using parallelism in slightly different manner: https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/697#_: tests were evenly split between N jobs, instead of repeating tests N times(as N jobs)
So, for flaky runner, I introducing a new ENV variable that would disable split for tests between parallel jobs and instead would run all test per each job.
Here is link to flaky runner build from this PR, which shows that all test runs per job
https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/736
* [artifacts] Fallback to port 443 when testing cloud deployments
The provided endpoint for ES from cloud no longer contains a port. When
a port is not provided to the FTR, it defaults to 9220 causing a
connection timeout. This sets the fallback to 443 instead.
* use process.env instead of interpolation
Kinda sneaky...since we already mutate the jest portion of the
file system (target/kibana-coverage/jest)
by dumping "jest unit" & "jest integration" coverage
into the same "final" directory...go ahead an make "jest integration"
use the same ran file designator as "jest unit".
This saves me from having to add logic for this later on.
This test was added as a verification step for daily releasable
artifacts. We had originally planned on the release manager consuming
this context. The expected workflow has changed now to us building and
publishing the docker image instead, which already has coverage in the
Build and Deploy to Cloud step.
* restructure performance tests for per journey config
* add cleanup hook to performance service for browser instance cleanup
* only enable APM in performance configs when TEST_PERFORMANCE_PHASE is set
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Spencer <spencer@elastic.co>
* aggregate and count routes added for kubernetes_security plugins.
includes FTR e2e tests. some e2e tests also created for session view plugin.
* naming fixes
Co-authored-by: mitodrummer <karlgodard@elastic.co>
* [QA][Code Coverage] fixup for auto config handling pr
## Summary
Embed buildkite pipeline definition.
Follow up pr to change cc per auto config handling.
Also, resolves https://github.com/elastic/kibana/issues/132706
Increase worker count for `node scripts/build_kibana_platform_plugins` to 4 workers.
Normalize file names within coverage files such that nyc correctly builds the combined summaries.
_Ci runs this on myriad servers, so the paths are different, which "breaks" nyc's output_
Split the final merge of functional coverage into 2 passes due to [nyc issue](https://github.com/istanbuljs/nyc/issues/1263)
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
- adds `parallelism: 4` for security_solution cypress buildkite pipeline
- added parsing /integrations folder with cypress tests, to retrieve paths to individual test files using `glob` utility
- list of test files split equally between agents(there are approx 70+ tests files, split ~20 per job with **parallelism=4**)
- small refactoring of existing cypress runners for `security_solution`
Old metrics(before @MadameSheema https://github.com/elastic/kibana/pull/127558 performance improvements):
before split: average time of completion ~ 1h 40m for tests, 1h 55m for Kibana build
after split in 4 chunks: chunk completion between 20m - 30m, Kibana build 1h 20m
**Current metrics:**
before split: average time of completion ~ 1h for tests, 1h 10m for Kibana build
after split in 4 chunks: each chunk completion between 10m - 20m, 1h Kibana build 1h
* [artifacts] Only upload beats artifacts if they exist
Beats artifacts are downloaded as a side effect of building the cloud
image. At times (e.g. a staging build, where we don't have the correct
sha) we may skip the cloud image build and these artifacts will not be
available to upload.
* Update .buildkite/scripts/steps/artifacts/build.sh
Co-authored-by: Spencer <email@spalger.com>
Co-authored-by: Spencer <email@spalger.com>
