This introduces a Node.js build with pointer compression enabled to our
serverless artifacts. Pointer compression is a v8 feature that can
reduce memory consumption. Details can be found at
https://v8.dev/blog/pointer-compression.
Impact depends on the workload. For idle projects we're seeing runtime
memory drop by ~33%.
### Implementation
Previously, build archives were created based on platform and CPU
architecture. Archives can now also be created with a variant. In this
case we're introducing a `serverless` variant. In the future we can
split this further per project type if needed.
The serverless variant installs two versions of Node.js: the existing
glibc-217 compatible version and the new pointer compression version.
Build scripts for the pointer compression version were introduced at
https://github.com/elastic/kibana-custom-nodejs-builds/pull/18.
kibana-serverless will default to using the pointer compression version.
### Tradeoffs
- Pointer compression builds have a heap limit of 4Gb. To mitigate this
we continue installing the glibc-217 compatible version and can swap
runtimes if a larger heap is needed.
- Pointer compression builds are not official Node.js builds
- Unofficial builds have been [functional since Node
14](https://github.com/nodejs/unofficial-builds/commits/main/recipes/x64-pointer-compression)
- We're already running an unofficial build to support operating systems
running older versions of glibc
Additional test runs:
https://buildkite.com/elastic/kibana-artifacts-snapshot/builds/4366https://buildkite.com/elastic/appex-qa-serverless-kibana-ftr-tests/builds/1884
Closes https://github.com/elastic/kibana/issues/96062
## Summary
Adds some messaging to direct developers toward the prod-ci vault, plus
CI docs links.
Also, removes branching that were added for the duration of the
migration. Since the PR build pipelines that are using these are
migrated, only one branch was active.
## Summary
https://github.com/elastic/kibana/issues/181683
This PR moves
1. x-pack/test/security_solution_endpoint_api_int to
`x-pack/test/security_solution_api_integration/test_suites/security_solution_endpoint_api_int`
2. x-pack/test/security_solution_endpoint to
`x-pack/test/security_solution_api_integration/test_suites/security_solution_endpoint`
3. x-pack/test/timeline to
`x-pack/test/security_solution_api_integration/test_suites/investigation/timeline`
### To test:
1. ```cd x-pack/test/security_solution_api_integration```
2. ```node ../../../scripts/functional_tests_server.js --config
./test_suites/security_solution_endpoint/serverless.endpoint.config.ts```
Once the server is launched (you might need Docker to run the serverless
tests), open another terminal, go to the same path, and execute the
command appears in the original:
The command should look like: ```node
../../../scripts/functional_test_runner
--config=test_suites/security_solution_endpoint/serverless.endpoint.config.ts```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Close https://github.com/elastic/kibana/issues/181992
## Summary
First iteration of a CLI to capture an OAS snapshot.
## How to test
Run `node ./scripts/capture_oas_snapshot.js --update --include-path
/api/status` and see result in `oas_docs/bundle.json`.
If you have the [bump CLI](https://www.npmjs.com/package/bump-cli)
installed you can preview the hosted output with `bump preview
./oas_docs/bundle.json`
## Notes
* Added ability to filter by `version`, `access` (public/internal) and
excluding paths explicitly to the OAS generation lib
* Follows the same general pattern as our other "capture" CLIs like
`packages/kbn-check-mappings-update-cli`
* Result includes only `/api/status` for now, waiting for other paths to
add missing parts
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Builds on: https://github.com/elastic/qaf-tests/pull/75
If we only rely on the 3-hour cycle of the QAF test suite as an
indication for a "releaseable" build, then we always work with this 3-4
hour lead time. This can make releasing on-demand very delayed.
@pheyos added `PRE_RELEASE_CHECK=true` to some builds, we can use this
as an indicator that a test run was meant to prove the releaseability of
a version.
This PR also moves the release assistant job together with other
ES_Serverless jobs.
## Summary
Some jobs were missing the notification channel, despite having
originally had notifications turned on.
This PR adds `SLACK_NOTIFICATIONS_CHANNEL: '#kibana-operations-alerts'`
here.
## 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>
## Summary
The FIPS pipeline may be failing for quite awhile for issues to get
fixed and as the project ramps up. For now divert the alerts to a new
Slack channel. Also adjusted the start time so that it completes earlier
in the day.
Approach with different configs for kibana ui and serverless was peek
out from security_solution test. 48 serverless config files are defined
in the test folder.
Test: no index
check no index message
Test: no connector
Add Index of example data (can be 10 docs into elasticsearch, BM25)
Add a connector (showing the modal)
verify the modal is shown
Test: with connector
seed ES with a connector in the test
Ask a question
Validate the connector has been called and respond back
validate the response is returned
validate the view query can be opened and content (query + fields) is as
expected
validate the edit context is can be opened and the fields is as expected
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>
This pull request introduces a new SO used for keeping relations between
artifactId and policyId. It addresses an issue where some users found
the single SO structure containing too many nested entries. Originally,
we planned to rewrite the existing Manifest Manager. However, during the
POC implementation, it became clear that the effort required to refactor
and retest the existing solution would be substantial. Therefore, this
pull request can be considered as the first step in transitioning our
approach from one SO to this new, distributed one.
The main idea behind these changes is to modify the structure of the SO,
rather than the logic of the Manifest Manager. To accomplish this, we
need to retrieve the SO from the new source, translate it into the
existing SO format (many SOs to one), execute the unchanged operations
of the Manifest Manager on artifacts, translate the resulting SO into
multiple SOs, and save them.
This change is expected to be deployed with a Feature Flag, and we need
to ensure that everything continues to function correctly in both cases.
Therefore, I've introduced a new FTR suite with the Feature Flag
enabled, which should be run alongside tests with the Feature Flag
disabled. This suite contains duplicated test files that depend on SO
logic. When we activate the Feature Flag, these tests should replace the
existing ones, as the Unified Manifest SO will become the default
approach.
It appears that there is no need to introduce any kind of migrations, as
the Manifest Manager is capable of recreating missing SOs (which has
been tested).
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closeselastic/kibana-operations#96
[new pipeline run](https://buildkite.com/elastic/kibana-fips/builds/28)
[old pipeline run](https://buildkite.com/elastic/kibana-fips/builds/24)
- Fixes OpenSSL compilation so that it does not overwrite the OS version
and break OS functionality.
- Fixes issue where ES would not start due to ML pipe being unable to
write to Vagrant synced folder.
- Reenabled ML in FIPS pipeline
- Fixes permission where Kibana could not write UUID file.
- Fixes smoke test exit code not reporting correctly.
- Fixes Buildkite annotation for failed tests
[example](https://buildkite.com/elastic/kibana-fips/builds/23).
- Switches the base VM image from RHEL9 to Ubuntu due to RHEL9
subscription requirements to install repo packages.
- This blocked installing Chrome, causing tests using Webdriver to fail.
---------
Co-authored-by: Dzmitry Lemechko <dzmitry.lemechko@elastic.co>
## Summary
On the new infra, the publish step will still require legacy vault
credentials and login.
(https://buildkite.com/elastic/kibana-artifacts-staging/builds/3513#018f7691-73c8-4e6f-862b-328b05d9de3b)
As a fix: this PR digs up the credentials from the vault instead of
gcloud secrets on the new infra.
Also, other usages of role-id/secret-id is used are moved in the
legacy-vault usages, plus minor code re-org, to reduce branching, and
future cleanup.
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 found that the command tries to log in to docker in cases when the
`docker` binary is available (installed) but not running on the devices.
This can happen, for example, on a device that's set up a bit
differently than our normal CI executors (e.g.: [bare metal
executors](https://buildkite.com/elastic/kibana-single-user-performance/builds/13383)).
This PR makes it sure that we only interact with docker in that step, if
it's running.
Originally `docker login` was localized to a single step and was managed
only in that step. Over time, this has expanded most pipelines and
steps. This changes the pattern to authenticate once during pre command.
## 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.
## Summary
https://github.com/elastic/kibana/issues/181683
This PR moves the existing Security Solution API integration tests from
`x-pack/test/api_integration/apis` to
`x-pack/test/security_solution_api_integration` and apply tags for each
scenario.
(x-pack/test/timeline is not included in this PR as this PR is already
big)
## Todo in the follow up PR:
move `x-pack/test/timeline` to
`x-pack/test/security_solution_api_integration` (as this PR is already
big)
## What to review?
1. Please review if the codeowner is assigned correctly.
2. Please review if the test cases are still valid.
## How to run the tests:
Here we use explore/hosts with trial license as an example:
```
cd ./x-pack/test/security_solution_api_integration
```
**Start ESS server:**
```
node ./scripts/index.js server explore trial_license_complete_tier hosts ess
```
When the server is started, open another terminal
```
cd ./x-pack/test/security_solution_api_integration
node ../../../scripts/functional_test_runner --config=test_suites/explore/hosts/trial_license_complete_tier/configs/ess.config.ts
```
**Start Serverless server:**
```
node ./scripts/index.js server explore trial_license_complete_tier hosts serverless
```
When the server is started, open another terminal
```
cd ./x-pack/test/security_solution_api_integration
node ../../../scripts/functional_test_runner --config=test_suites/explore/hosts/trial_license_complete_tier/configs/serverless.config.ts
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
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.
Fixes https://github.com/elastic/kibana/issues/182637
## Summary
This PR introduces our first functional tests for the SLO Overview
Embeddable with a bunch of helper functions to interact with the
different UI elements. Here are the basic scenarios that have been
covered:
- Add a single SLO Overview panel
- Verify the configuration flyout opens
- Verify the SLO selection dropdown exists
- Verify the Save button is enabled
- Verify an SLO Overview panel is added
- Verify the title is present
- Add a group SLO Overview panel
- Verify the overview mode selector exists and opens the group
configuration screen
- Verify the Group by dropdown exists
- Verify the Group dropdown exists
- Verify the KQL bar exists
- Verify an SLO Group Overview panel is added
Here's a list of scenarios that need to be covered in a follow up PR (I
will create a separate ticket with following acceptance criteria):
- Check that clicking on the SLO card item opens the SLO details flyout
- Check that clicking on the group expands the accordion and shows the
respective SLOs
- Check that `Edit criteria` link exists in the Group embeddable
- Interact with edit criteria link
- Check that selected group by is shown
- Check that selected group is shown
- Check that custom filter is shown in the kql bar
- With Remote enabled
## How to test
```
node scripts/functional_tests_server.js --config x-pack/test/functional/apps/slo/embeddables/config.ts
node scripts/functional_test_runner --config=x-pack/test/functional/apps/slo/embeddables/config.ts
```
## 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>
## Summary
Related to #181733 - I didn't check, and axios rejects requests'
promises that don't result in `2xx`.
This PR wraps the attempt in a try-catch to be able to retry.
