Closes https://github.com/elastic/kibana/issues/186631
Closes https://github.com/elastic/kibana-operations/issues/151
Adds a daily pipeline for running our jest and integration tests against
a Node.js distribution with pointer compression enabled. This is enabled
by setting the environment variable
`CI_FORCE_NODE_POINTER_COMPRESSION=true`
I would prefer a cleaner implementation, but I'm not seeing a way around
it without changing our defaults globally. Open to ideas. We have to
update three downloads:
1) base node.js install, for jest
2) build node.js install, for integration tests
3) bazel workspace install, for dependencies
https://buildkite.com/elastic/kibana-pointer-compression/builds/6
---------
Co-authored-by: Tiago Costa <tiago.costa@elastic.co>
adduser is used in the deb post install script. Installing kibana.deb in
a container won't have the necessary dependencies by default
Closes#182537
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
These were used for testing the migration from the kibana-buildkite
infra to the elastic-wide buildkite infra. Now we're done with most of
the migration, we can clean these up.
## Summary
The Threat Hunting API tests are not part of our QGs, in this PR we are
adding them to it.
Once this PR is merged:
- All the API tests marked as `@serverless` are going to be executed as
part of the periodic pipeline
- Once this other [PR](https://github.com/elastic/kibana/pull/187266) is
merged, all the API tests marked as `@serverlessQA` will be executed as
part of the Kibana QA QG (second quality gate).
---------
Co-authored-by: dkirchan <diamantis.kirchantzoglou@elastic.co>
## Summary
Currently is not possible to see at first sight which execution is from
Cypress and which one from API.
<img width="2545" alt="Screenshot 2024-07-02 at 17 18 04"
src="c89c204d-e2cf-4661-87f4-1e206ad822d7">
In this PR we are updating the naming to make it easier to find out as
well as simplifying the names.
## Summary
This PR adds separately quality gate pipelines for the emergency release
process.
More details in the original PR #186833, which is split into the
creation of the new pipeline (this PR) and moving existing pipelines
from `catalog-info.yaml` to `.buildkite/pipeline-resource-definitions`
(#187253).
## Summary
Some references to `elastic-images-qa` were left in the code, probably
as these pipelines were on a pending PR when the rest got changed.
Optionally, we should remove all the `imageProject` fields, and
everything we're setting defaults - it's just generating bloat.
## Summary
This PR adds separately quality gate pipelines for the emergency release
process.
This gives us the opportunity to run a different set of checks during an
emergency release compared to a regular release.
### Details
- Add new emergency quality gates pipeline definitions in
`.buildkite/pipelines/quality-gates/emergency`. These are copies of the
regular quality gates pipeline files with the following adjustments:
- The entry point `kibana-serverless-quality-gates-emergency.yml` has an
adjusted `QG_PIPELINE_LOCATION` and comment
- The QA quality gates in `pipeline.tests-qa.yaml` is reduced to just
the CP e2e tests
- Add new pipeline
`.buildkite/pipeline-resource-definitions/kibana-serverless-quality-gates-emergency.yml`
is added that will trigger the emergency version of the quality gates.
### Other changes
In order to have things around the serverless quality gates and the
emergency release consistent, I've taken the opportunity and moved the
definitions of the following pipelines from `catalog-info.yaml` to
`.buildkite/pipeline-resource-definitions`
- `buildkite-pipeline-kibana-emergency-release` ->
`.buildkite/pipeline-resource-definitions/kibana-serverless-emergency-release.yml`
- `kibana-tests-pipeline` ->
`.buildkite/pipeline-resource-definitions/kibana-serverless-quality-gates.yml`
## Summary
When we're seeing errors in FTR or on the serverless verification
pipeline, we have difficulty connecting back what version of
ES-Serverless is behind the tag `:latest`.
With a recent addition to the ES Serverless docker image, this info is
now contained in labels of the image.
This PR highlights this info in the verification pipeline, as well as
the FTR output from `kbn-es`.
- Serverless verification pipeline:
https://buildkite.com/elastic/kibana-elasticsearch-serverless-verify-and-promote/builds/1454
- FTR:
- removes parallelism: 2 from step definition. The test suites are not
sharded.
- Updates the path used to trigger a test run. The previous path is out
of date.
## Summary
Migrates (without history preservation) the emergency release branch
testing job to the new infra
Verified through:
- [x] locally tested the pipeline definition file
- [x] ran the testing pipeline through the migration staging job
(https://buildkite.com/elastic/kibana-migration-pipeline-staging/builds/125#_)
## Summary
- Closes https://github.com/elastic/kibana-operations/issues/100
- Utilizes FIPS agent from elastic/ci-agent-images#686
- Adds dynamic agent selection during PR pipeline upload
- FIPS agents can be used with `FTR_ENABLE_FIPS_AGENT` env variable or
`ci:enable-fips-agent` label
- Removes agent image config from individual steps in favor of image
config for the whole pipeline.
- Steps can still override this config by adding `image`, `imageProject`
etc
- Adds a conditional assertion to `Check` CI step which validates that
FIPS is working properly
### Testing
- [Pipeline run using FIPS
agents](https://buildkite.com/elastic/kibana-pull-request/builds/215332)
- Failures are expected and this possibly ran with flaky tests
In this PR a chain of pipeline structures is introduced.
For each different solution team, depending on the flag
KIBANA_MKI_QUALITY_GATE, if it is '1' it uploads the respective team
pipeline from the path
`.buildkite/pipelines/security_solution_quality_gate/mki_quality_gate`
otherwise it uses the respective pipeline from the path
`.buildkite/pipelines/security_solution_quality_gate/mki_periodic`.
For the quality gate, the cypress tests will be using for now the level
of parallelism equal to 1 as not many tests are yet enabled.
For the periodic pipeline the original level of parallelism is
respected.
Co-authored-by: Gloria Hornero <gloria.hornero@elastic.co>
## Summary
This PR splits the API Integration test suite from one pipeline
including all tests to using the already existing pipelines for the
security quality gate and splitting the TS scripts per team.
With this PR merged the following should happen:
- The [FTR API integration
tests](https://buildkite.com/elastic/kibana-serverless-security-solution-quality-gate-api-integration/builds/445)
pipeline should be removed
- All the scripts of this pipeline are split to the relevant team
pipelines. For example the team which maintains the tests should be able
to see the following structure when a build is triggered. (The noted
group is the API tests for the specific team)
<img width="1182" alt="Screenshot 2024-05-20 at 5 56 49 PM"
src="87c1fc1c-4425-4756-890f-b458da0e189a">
- In order to identify why the build is triggered, (Quality gate OR
Periodic Pipeline) the following two snippets will define the _triggered
by_ information.
---
**Triggered By Quality Gate**
<img width="1156" alt="Screenshot 2024-05-20 at 5 21 04 PM"
src="0e3e8928-7306-44ee-acd8-4368d93e452d">
** Triggered By Periodic Pipeline **
<img width="1154" alt="Screenshot 2024-05-20 at 5 49 11 PM"
src="aa8d6591-a612-4f60-a433-c80e213bc6b8">
---------
Co-authored-by: Gloria Hornero <gloria.hornero@elastic.co>
This PR contains the following updates:
| Package | Update | Change |
|---|---|---|
| docker.elastic.co/ci-agent-images/quality-gate-seedling | patch |
`0.0.2` -> `0.0.4` |
---
### Configuration
📅 **Schedule**: Branch creation - At any time (no schedule defined),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR has been generated by [Renovate
Bot](https://togithub.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy4zNjMuOSIsInVwZGF0ZWRJblZlciI6IjM3LjM2My45IiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6W119-->
Co-authored-by: Renovate Bot <bot@renovateapp.com>
Adds a new docker image, `kibana-chainguard` using
[chainguard-base](https://images.chainguard.dev/directory/image/chainguard-base).
For now this is only for testing, exact naming tbd.
Testing
```
docker load < kibana-chainguard-8.15.0-SNAPSHOT-docker-image-aarch64.tar.gz
docker run --rm docker.elastic.co/kibana/kibana-chainguard:8.15.0-SNAPSHOT
```
## Summary
We've recently seen a handful of step timeouts when running type-checks.
While this is not the best solution, it mitigates for potential builds
failed, and retries due to timeouts.
This PR also contains some cleanup around previous, type-check related
jobs (e.g.: the [type-check issue of 2023
august](https://github.com/elastic/kibana/pull/167060))
## Summary
Extends the flaky-test-runner with the capability to comment on the
flaky test runs on the PR that's being tested.
Closes: https://github.com/elastic/kibana/issues/173129
- chore(flaky-test-runner): Add a step to collect results and comment on
the tested PR
## Summary
We stuck with using the `elastic-images-qa` because that's how we
initially set up the migration scripts and didn't bother to switch over
once we got the images working as most of the pipelines were low-risk,
and a potential issue would have been easy to fix.
While the same image goes to QA and prod every day, moving forward, we
need to allow some experimentation at the QA images level, as we work on
the caching and further optimizations. We shouldn't allow that
experimentation to affect the already migrated pipelines.
This PR switches over to using the `elastic-images-prod` repo. Images
get promoted here if they're built from the `main` of
https://github.com/elastic/ci-agent-images, or promoted manually from a
branch build.
This change should not affect existing behavior.
We didn't test every pipeline but the assumption is that if one works,
all works:
https://buildkite.com/elastic/kibana-migration-pipeline-staging/builds/94
Will merge this once 8.13 is no longer active.
This splits the project build and deploy steps into two: build the
container image, and then deploy. This will allow us to build the
project image in parallel with other checks, and deploy later after a
smoke test is completed. Currently this uses static checks of:
- project image build
- linting
- lint with types
- checks
- type check
Time to project deployment is expected to be ~5~ 1 minute longer. If
needed we can expand to functional tests, but in the interim this should
cover the issue we saw in https://github.com/elastic/kibana/pull/180309.
## Summary
This PR is addressing the following issues:
- The pipelines defined in
`.buildkite/pipeline-resource-definitions/security-solution-quality-gate/`
folder were skipping intermediate builds. We need to be able to run more
than one build in the same time for these pipelines.
- As part of the refactoring / optimization of the
`.buildkite/scripts/pipelines/security_solution_quality_gate/api_integration/api-integration-tests.sh`
script, it now executes a TS script in order to handle the projects for
serverless and execute the yarn script provided.
- As part of this refactoring, the methods and worfklow defined in the
`x-pack/plugins/security_solution/scripts/run_cypress/parallel_serverless.ts`
is now followed in order to reduce code duplication and maintenance.
- Fixed an issue in
`x-pack/test/security_solution_api_integration/scripts/index.js`. This
issue was causing false green test executions in buildkite. The exit
code was not actually returned from the child process so the exit code
of this script was 0, even though the child process (test execution) was
failing giving back an exit code 1.
- Parameterized
`.buildkite/pipelines/security_solution/api_integration.yml` to be
running the correct test suite (release or periodic) depending on
whether the environment variable `QUALITY_GATE=1` is passed or not.
The last bullet was misleading the test results interpretation, reading
as successful test runtime scripts which had one or more test failures.
E.g: [Buildkite Test Execution being green with failing
tests.](https://buildkite.com/elastic/kibana-serverless-security-solution-quality-gate-api-integration/builds/307#018f3409-c062-4edf-9663-3ba785823a6c/294-757)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
