This PR is a simple update of our pipeline resource definition files
after the recent bumps.
---------
Co-authored-by: Jonathan Budzenski <jon@elastic.co>
## Summary
This PR moves 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`
More details in the original PR #186833, which is split into the
creation of the new pipeline (#187251) and moving existing pipelines
from catalog-info.yaml to .buildkite/pipeline-resource-definitions (this
PR).
## 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
Summarize your PR. If it involves visual changes include a screenshot or
gif.
This PR add Automation Credentials buttons for GCP and AWS. UX copy will
be addressed in the [folllowing
ticket](https://github.com/elastic/kibana/issues/178858).
<img width="900" alt="image"
src="f7329fa7-ae48-4dc0-a7cf-a0a26d80ad6b">
For Agentless the CSPM AWS integrations, users will able to :
* click Launch Cloud Formation button for single account or organization
account which opens external link to Cloud Formation page.
* create a cloud formation stack that generates access keys.
We will use the Cloud Formation template url from the package info
`getTemplateUrlFromPackageInfo` exposed as common utility in fleet.
<img width="884" alt="image"
src="d5e5e7d2-21fe-44bc-88e7-908d29817dfb">
For Agentless the CSPM GCP integrations, users will able to click Launch
Cloud Shell button for single accounts or organization account. We get
the cloud shell template url from the package info
`getTemplateUrlFromPackageInfo`
## To test PR:
AWS
1. Log in as an admin in the management account of the AWS Organization
you want to onboard
2. Click the Launch CloudFormation button below.
3. (Optional) Change the Amazon region in the upper right corner to the
region you want to deploy your stack to
4. Tick the checkbox under capabilities in the opened CloudFormation
stack review form: I acknowledge that AWS CloudFormation might create
IAM resources.
5. Click Create stack.
6. Once stack status is CREATE_COMPLETE then click the Outputs tab
7. Copy Access Key Id and Secret Access Key then paste the credentials
below
Use: `eu-west-1` region to create stacks
GCP
1.Replace <PROJECT_ID> in the following command with your project ID
then copy the command
2. Click Launch Google Cloud Shell, then run the command
3. Check `Trust Repo` and click `CONFIRM` button
5. Paste and run command in the cloud shell terminal
Cloud Security team `gcloud config set project test-project-1-396010 &&
ORG_ID=693506308612 && ./deploy_service_account.sh`
5. Run 'cat KEY_FILE.json' to view the service account key. Copy and
paste it in the CSPM GCP integration.
Internal Team Developer Tips for testing :
- Look for `cloudshell_git_branch` in the url and change `8.XX` to
`main`.
- To run script, see command
[here](https://p.elstc.co/paste/XyJg0wW8#srnavdS0GZtxapNA1ZcNu9TddLpG+zWP-99KWWpIEnr)
-
Any question for GCP account issue reachout to @orouz
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## 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
Renames the experimental asset_manager plugin (never
documented/officially released) into entity_manager. I've used `node
scripts/lint_ts_projects --fix` and `node scripts/lint_packages.js
--fix` to help with the procedure and also renamed manually the
asset_manager references left.
The change also removes the deprecated asset_manager code, including the
`assetManager.alphaEnabled` plugin configuration. This means
entityManager plugin will be enabled by default.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Added FTR configs over http2 for security tests.
- `security_api_integration/oidc.http2.config.ts`
- `security_api_integration/saml.http2.config.ts`
- `security_functional/oidc.http2.config.ts`
- `security_functional/saml.http2.config.ts`
### Checklist
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
__Fixes: https://github.com/elastic/kibana/issues/184769__
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## 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#_)
This adds the use of the `-f` flag to `curl` commands so that the
`deploy.sh` script will fail if an HTTP response is not 2xx.
This will prevent, for example, us from thinking that an update of a
project worked when instead the API responded `405` and nothing happened.
Related to https://github.com/elastic/kibana/pull/186543.
## 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
## Summary
This PR adds endpoints for managing builtin entity discovery:
- `GET /internal/api/entities/managed/enablement`: check if stored API
key exists and is valid, then checks whether builtin definitions are
installed and running
- `PUT /internal/api/entities/managed/enablement`: creates API key if
none exists, then installs and kickoff the builtin definitions
- `DELETE /internal/api/entities/managed/enablement`: stops and
uninstalls builtin definitions, then delete API key
- `GET /internal/api/entities/definition`: returns the definitions
installed and their corresponding state `{ installed: bool, running:
bool }`
The API key is stored in an encrypted saved object, and has only the
permissions required to manage the transforms/ingest pipelines, and read
the source data.
Built in definitions are stored in code and have hardcoded IDs with a
special prefix `builtin_`.
The change also includes an `entityClient` that can be consumed by
public plugins and exposes methods that proxy the http endpoints listed
previously.
### Testing
- verify entity discovery is not enabled with `GET
kbn:/internal/api/entities/managed/enablement`
- setup entity discovery with `PUT
kbn:/internal/api/entities/managed/enablement`
- verify builtin definitions are installed and running `GET
kbn:/internal/api/entities/definition?builtIn=true`
- verify entity discovery is enabled with `GET
kbn:/internal/api/entities/managed/enablement`
- disable entity discovery with `DELETE
kbn:/internal/api/entities/managed/enablement`
- verify builtin definitions are not installed anymore `GET
kbn:/internal/api/entities/definition?builtIn=true`
- verify entity discovery is disabled with `GET
kbn:/internal/api/entities/managed/enablement`
---------
Co-authored-by: Kevin Lacabane <kevin.lacabane@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
# Pull Request Overview
This pull request (PR):
1. Enables Product Types for FTR API Integration Test Suites in
Serverless MKI:
- Previously, the test suites ignored product types entirely. With this
PR, scripts to run the tests have been relocated to
x-pack/test/security_solution_api_integration/scripts.
- Users can now run tests from the API Integration tests directory for
security solutions by using the command:
TARGET_SCRIPT={script_from_package_json} node
./scripts/mki_start_api_ftr_execution. This will execute the following
steps:
1. Create a security serverless project, respecting the product types
specified in the serverless configuration found in the config folder of
the relevant test suite.
2. Reset credentials.
3. Wait for Elasticsearch (ES) and Kibana to be ready and available.
4. Execute the tests.
5. Delete the project upon completion.
2. Adds Proxy Services Organizations to .ftr Role Users Files:
- This PR updates the .ftr role_users files to include all proxy
services organizations, ensuring they have the necessary permissions for
the tests.
# Implementation Details
Product Types
- Previous Setup:
- A project was created and handed over to the test suite to run the API
tests against, without considering product types.
- Changes Introduced:
- The script execution for tests has moved to
x-pack/test/security_solution_api_integration/scripts.
- Tests can be initiated using the command from the API Integration
tests folder where package.json exists:
```
TARGET_SCRIPT={script_from_package_json} node
./scripts/mki_start_api_ftr_execution
```
- The mki_start_api_ftr_execution script performs several steps to run
the tests, including creating a security serverless project with
specified product types, resetting credentials, ensuring ES and Kibana
readiness, executing tests, and cleaning up the project afterward.
- The script reads extra configuration (currently only product types are
supported) in the specific format as is, from the following file :
[api_configs.json](https://github.com/elastic/kibana/pull/184309/files#diff-1122baffe7ff843b1f486cee95468bed5851a9a4934be747f540bd42dc9a07daR2).
The key for the JSON file is the name of the script in
[package.json](https://github.com/elastic/kibana/pull/184309/files#diff-c6af1c81947b3a77bed431c688c7ad38c8969bd52e1c3ea92d643f09d422eb61R296)
- If a specific configuration is not required and the default complete
project is needed for the test to run, the key and configuration in the
`api_configs.json` file can be ommitted.
# Summary
This PR enhances the flexibility and functionality of the FTR API
integration test suites for serverless MKI by incorporating product type
considerations and updating the role_users configuration to include
proxy services organizations.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
With the migration to the shared buildkite infra, we've also switched to
using the ci-prod vault (https://vault-ci-prod.elastic.dev) for all
CI-related secrets. We found it reasonable then, to also switch the
storage of the credentials for the deployments there. It's since been
proven unnecessary, even confusing for developers, as they might not be
adequately set up for accessing the two vaults. We've also learned, that
both of these vault instances are here to stay, so there's no push to
migrate everything to the ci-prod instance.
So, this PR switches back to using the legacy vault in all cases for
storing deployment keys, as it fits better with the developers' daily
secret handling duties.
Also, adds a cleanup part to the purge routine.
- [x] extract vault read / write to a parametric shell script, because
the typescript invocations to vault won't have an easy access to the
`set_in_legacy_vault`
## Summary
Closes https://github.com/elastic/kibana/issues/184025
This PR enables the migration from Ace to Monaco in Dev Tools Console by
default in the main branch. All serverless projects will still have the
migration disabled by default. After 8.15 is branched, the migration
will be disabled there as well. The intended release version for this
migration is 8.16.
### Functional tests
This PR creates a copy of functional tests for Monaco Console and keeps
the tests for Ace in a separate folder. When the migration is released,
we can remove the code for Ace together with tests.
The Monaco tests are not the exact copy of the Ace tests, since some
functionality and autocomplete behaviour is slightly different in the
migrated Console. For example, the auto-closing of brackets works in
Monaco when typing something, but is not kicking in in the tests.
Flaky test runner
### Checklist
Delete any items that are not applicable to this PR.
- [ ] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)
- [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [ ] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [ ] Any UI touched in this PR is usable by keyboard only (learn more
about [keyboard accessibility](https://webaim.org/techniques/keyboard/))
- [ ] Any UI touched in this PR does not create any new axe failures
(run axe in browser:
[FF](https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/),
[Chrome](https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US))
- [ ] If a plugin configuration key changed, check if it needs to be
allowlisted in the cloud and added to the [docker
list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)
- [ ] This renders correctly on smaller devices using a responsive
layout. (You can test this [in your
browser](https://www.browserstack.com/guide/responsive-testing-on-local-server))
- [ ] This was checked for [cross-browser
compatibility](https://www.elastic.co/support/matrix#matrix_browsers)
### Risk Matrix
Delete this section if it is not applicable to this PR.
Before closing this PR, invite QA, stakeholders, and other developers to
identify risks that should be tested prior to the change/feature
release.
When forming the risk matrix, consider some of the following examples
and how they may potentially impact the change:
| Risk | Probability | Severity | Mitigation/Notes |
|---------------------------|-------------|----------|-------------------------|
| Multiple Spaces—unexpected behavior in non-default Kibana Space.
| Low | High | Integration tests will verify that all features are still
supported in non-default Kibana Space and when user switches between
spaces. |
| Multiple nodes—Elasticsearch polling might have race conditions
when multiple Kibana nodes are polling for the same tasks. | High | Low
| Tasks are idempotent, so executing them multiple times will not result
in logical error, but will degrade performance. To test for this case we
add plenty of unit tests around this logic and document manual testing
procedure. |
| Code should gracefully handle cases when feature X or plugin Y are
disabled. | Medium | High | Unit tests will verify that any feature flag
or plugin combination still results in our service operational. |
| [See more potential risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx) |
### For maintainers
- [ ] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
rename `SLACK_NOTIFICATIONS_ENABLED` =>
`ELASTIC_SLACK_NOTIFICATIONS_ENABLED` to follow up on elastic-wide
buildkite changes.
This should re-enable test failure listing on the slack errors we post.
**Addresses:** https://github.com/elastic/kibana/issues/184428
## Summary
This PR adds scripts for automatic bundling Detections API OpenAPI spec as a part of PR pipeline. Corresponding resulting bundles are automatically committed to `x-pack/plugins/security_solution/docs/openapi/ess/` and `x-pack/plugins/security_solution/docs/openapi/serverless` folders.
After migrating to gobld, the string identifying spot instances has
changed. This updates the check to determine if there are retries
available by filtering on the metadata for both gobld and
buildkite-agent-manager.
## Summary
Only adds build_project.yml if there's not already a deploy_project.yml
added through labels
## Context
Based on the labeling logic, if we had `ci:build-serverless-image` and
`ci:project-deploy-*`, the steps for building the docker image would be
added twice.
See: https://elastic.slack.com/archives/C0D8P2XK5/p1718268306523329
resolves: https://github.com/elastic/kibana/issues/181325
## Summary
Adds a new task claiming strategy `unsafe_mget`, which can be used instead of
the default one `default`. Add the following to your `kibana.yml` to
enable it:
xpack.task_manager.claim_strategy: 'unsafe_mget'
## Summary
Resolves https://github.com/elastic/kibana/issues/183419.
Adds a performance journey that performs the same tests as the existing
Discovery journey.
To run locally:
```
node scripts/run_performance.js --journey-path x-pack/performance/journeys_e2e/many_fields_discover_esql.ts
```
