[Security Solution] Adds serverlessQA tag to the API tests #180773

MadameSheema · 2024-04-15T08:52:26Z

Continues #179737 effort we are aligning the tags on Cypress and API to have a unified experience.

Summary

We want to start integrating our Cypress tests with the serverless Kibana quality gate. However, not all the teams feel comfortable enabling all the tests, to facilitate the effort of enabling tests in the quality gate we are adding the @serverlessQA tag, now on API tests as well.

We use tags to select which tests we want to execute on each environment and pipeline.

ess - runs in ESS env
serverless - runs in serverless env and periodic pipeline (failures don't block release)
serverlessQA - runs in kibana release process (failures block release)
skipInEss - skipped for ESS env
skipInServerless - skipped for all serverless related environments
skipInServerlessMKI - skipped for MKI environments

Description

Tests tagged as @serverless

All the tests tagged as @serverless will be executed as part of the PR validation process using the serverless FTR environment (not a real one). That tests will be executed as well as part of the periodic pipeline using a real serverless project. QA environment is used to do so using the latest available commit in main at the time of the execution.

Tests tagged as @serverlessQA

All the tests tagged as @serverlessQA will be executed as part of the kibana release process using a real serverless project with the latest image available in the QA environment

Tests tagged as @ess

All the tests tagged as @ess will be executed as part of the PR validation process using an on-prem ESS environment.

Tests tagged as @skipInServerless

All the tests tagged as @skipInServerless will be excluded from the PR validation process using the serverless FTR environment, the periodic pipeline and kibana release process for Serverless.

Tests tagged as @skipInEss

All the tests tagged as skipInEss will be excluded from the PR validation process using an on-prem ESS environment.

MadameSheema · 2024-04-15T08:52:46Z

/ci

elasticmachine · 2024-04-15T10:22:38Z

Pinging @elastic/security-solution (Team: SecuritySolution)

hop-dev

Entity analytics changes LGTM 🚀

MadameSheema · 2024-04-15T11:52:34Z

/ci

spong

Security GenAI tag updates LGTM! 👍

Thanks for the clear communication and update here @MadameSheema!

MadameSheema · 2024-04-15T18:56:30Z

/ci

MadameSheema · 2024-04-16T08:06:25Z

/ci

MadameSheema · 2024-04-17T14:00:58Z

/ci

rylnd

I had a few nits about definitions/discoverability, and it looks like a few of the build commands are missing their kibana commands (which needs to be fixed), but otherwise this LGTM.

.buildkite/pipelines/security_solution/api_integration_serverless_release.yml

rylnd · 2024-04-17T16:57:56Z

.buildkite/pipelines/security_solution/api_integration_serverless_release.yml

+              limit: 2
+
+      - label: Running exception_operators_date_numeric_types:qa:serverless:release
+        command: .buildkite/scripts/pipelines/security_solution_quality_gate/api_integration/api-integration-tests.sh exception_operators_date_numeric_types:qa:serverless:release


How does one trace this command to the tests/code that it executes?

The key exception_operators_date_numeric_types:qa:serverless:release is the only argument to the test script, but that key only exists in this file. The test script seems to just call yarn run [key], but I don't see how yarn run exception_operators_date_numeric_types:qa:serverless:release works if that command isn't defined somewhere.

Update: I see that I chose a key that was (accidentally?) omitted from x-pack/test/security_solution_api_integration/package.json.

That answers my question about discoverability, but means that some of these are going to fail until the corresponding commands are defined.

It looks like either a wrong key usage or a lack of update in the branch with the latest code. @MadameSheema

rylnd · 2024-04-17T17:39:15Z

x-pack/test/security_solution_api_integration/README.md

+- We are using the following tags:
+   * `@ess`: Runs in an ESS environment (on-prem installation) as part of the CI validation on PRs.
+
+   * `@serverless`: Runs in the first quality gate and in the periodic pipeline.


The only other mention of "first quality gate" is in the cypress README; I think it's worth defining these terms in some detail since they're not going to be self-evident to everyone.

Same thing for "periodic pipeline," "second quality gate," and "all quality gates."

Hey @rylnd everything is already documented.

@MadameSheema it's wonderful that it's documented, but how does someone reading this README find those definitions? You shared links to quality gates and periodic pipeline with me individually, but that process does not scale, so I'm proposing that we somehow reference that documentation here.

If we are reluctant/unable to share those docs because they're internal, I think that might be indication that this README either covers too much or is in the wrong place; our public documentation shouldn't reference internal processes that the reader has no insight on.

++ to @rylnd's comment

Yup, share it with you in private due to being internal documentation, tbh I don't know what is best, thoughts? What do you prefer?

I think the ideal approach in my mind would be:

Internal documentation associating the cypress tags to our CI/QA infrastructure/processes

Public documentation with definitions appropriate to those not involved in our operations

I'm imagining a contributor who's written a cypress test for a feature they'd like to add; I would not expect them to know/care about any of these tags. As part of the review process, an Elastician would tell them which tags need to be added to their tests.

Generally: if we can't provide the reader with enough information to determine whether they should use the tag, I don't think that it's helpful to mention it at all.

Maybe a passing mention of the tags as "related to internal release processes" would be a way to both define the tags but also deemphasize them, here?

rylnd · 2024-04-17T17:53:52Z

x-pack/test/security_solution_api_integration/README.md

+
+   * `@serverless`: Runs in the first quality gate and in the periodic pipeline.
+
+   * `@serverlessQA`: Runs in the second quality gate.


This tag seems to be strongly tied to the concept of a "release" (as evidenced in the command names, and this PR's description), but that isn't really reflected in either the README here nor in the tag name itself.

Would @serverlessRelease be a more accurate and descriptive tag name?

As part of the release, the tests might be executed as part of 2 other quality gates and we might have some on the second one that we don't want to execute it on the third one.

IMO referencing the "gate order" might be the most straightforward way to express this; it's not intuitive that QA represents "second gate," nor what the other gates are.

x-pack/test/security_solution_api_integration/README.md

…ess_release.yml Co-authored-by: Ryland Herrick <[email protected]>

Co-authored-by: Ryland Herrick <[email protected]>

…ess_release.yml Co-authored-by: Ryland Herrick <[email protected]>

banderror · 2024-04-18T12:43:41Z

..._prebuilt_rules_package/trial_license_complete_tier/install_latest_bundled_prebuilt_rules.ts

@@ -31,7 +31,7 @@ export default ({ getService }: FtrProviderContext): void => {
  /* from a package that was bundled with Kibana */
  //
  // FLAKY: https://github.com/elastic/kibana/issues/180087
-  describe.skip('@ess @serverless @skipInQA install_bundled_prebuilt_rules', () => {
+  describe.skip('@ess @serverless @skipInServerless install_bundled_prebuilt_rules', () => {


@MadameSheema We don't want all the tests for prebuilt rules to be skipped in all quality gates. We need them to run on CI, where, as far as I'm aware, they are not currently skipped and have been passing.

This also applies to some of the other rule management tests that are being skipped in CI by this PR.

I would suggest to:

Either introduce an additional @skipInServerlessMKI tag and use it for these tests instead of @skipInServerless. This tag would skip a test in the periodic pipeline + 2nd quality gate + 3rd and 4th quality gates in the future, but keep the test running on CI in the Serverless mode.

Or to rename the @serverless tag to @serverlessCI and introduce:

an additional tag @serverlessRelease that would add a test to all the release pipelines: the 2nd quality gate + 3rd and 4th quality gates in the future

an additional tag @serverlessPeriodic that would add a test only to the periodic pipeline

I'd personally choose the 2nd option as being more explicit about where a test should run.

Sorry if I missed this in #179737 where Cypress tests for prebuilt rules and rule management have been skipped in Serverless CI. We'd need to run those Cypress tests in CI too, so I'd propose the same changes for Cypress tests.

cc @jpdjere @maximpn @xcrzx

@maximpn @yctercero since you were the ones against having extra labels, can you please arrive to an agreement about how to proceed with it?

This is my proposal:

@serverless -> Executes tests on CI and periodic pipeline (MKI)  
@serverlessQA -> Executes tests on the second quality gate (QA environment)  @skipServerless-> Does not execute the test in any serverless environment 
@skipServerlessMKI -> Does not execute the test in any MKI environment (periodic pipeline and quality gate)  

If you don’t want a test to be executed as part of the second quality gate you don’t add the @serverlessQA tag to it.

@MadameSheema do I get it correctly a test which should be skipped in MKI env but run everywhere else will have the following tags

describe('@ess @serverless @serverlessQA @skipServerlessMKI install_bundled_prebuilt_rules', () => {

Here we return to the situation when it equals to

describe('@ess @serverless install_bundled_prebuilt_rules', () => {

Here we have two options

Have only @ess, @skipInEss, @serverless, @serverlessQA and @skipInServerless tags. When we need to run a test in another MKI end we would add another @serverless<name> tag. By default we just don't add tags so the test isn't enabled automatically for any MKI environment. There is an assumption MKI env is less stable than mocked Serverless env. It's impossible to disabled a test for only mocked Serverless env but still run it against some MKI env. But it doesn't look like an issue.

Have only @ess, @skipInEss, @serverless, @skipInServerlessMock (what's the best name for local/CI Serverless instead of serverless mock?) and @skipInServerlessQA tags. In this case tests tagged by @serverless will run against everything (besides ESS) and adding a corresponding @skipInServerless<name> tag skips a test in a proper env.

The second approach looks better for automatic skipping script. When a test fails in some env or becomes flaky it could be skipped automatically.

I checked the PR's diff once more time and see that it's more convenient to use the second approach. Quite often describe section has permissive tags @ess and @serverless while individual tests have may be skipped via @skipInServerless. It will require manually skip all the tests in MKI env via @skipInServerlessQA but it should be simpler to maintain the tests.

@maximpn

Have only @ess, @skipInEss, @serverless, @serverlessQA and @skipInServerless tags.

This set of tags doesn't allow to run a test on CI in ESS + on CI in Serverless, but not run it in the periodic pipeline + release gates.

At this point, we need to be able to run many of our tests ONLY on CI in ESS + on CI in Serverless, because they are broken in MKI environments. Fixing this requires time and effort we don't have at the moment.

Have only @ess, @skipInEss, @serverless, @skipInServerlessMock (what's the best name for local/CI Serverless instead of serverless mock?) and @skipInServerlessQA tags

This set of tags also doesn't allow to run a test on CI in ESS + on CI in Serverless, but not run it in the periodic pipeline + release gates.

We don't need to be able to skip a test on CI in Serverless, but run it in MKI pipelines. We don't have such class of tests as of now.

@banderror @MadameSheema

Could you clarify the requirements to running tests in periodic pipeline? Do we need a separate way to skip tests for periodic pipeline?

In my understanding if a test is broken in MKI env it will be broken in periodic pipeline since it's an MKI env as well. Taking this into account a test shouldn't have @serverlessQAtag (option 1) or have @skipInServerlessQA tag (option 2). It won't run against any MKI env until it's fixed, tested manually and tag manipulation is performed to run the test against MKI envs.

@banderror @MadameSheema

Could you clarify the requirements to running tests in periodic pipeline? Do we need a separate way to skip tests for periodic pipeline?

In my understanding if a test is broken in MKI env it will be broken in periodic pipeline since it's an MKI env as well. Taking this into account a test shouldn't have @serverlessQAtag (option 1) or have @skipInServerlessQA tag (option 2). It won't run against any MKI env until it's fixed, tested manually and tag manipulation is performed to run the test against MKI envs.

As there are differences between the serverless environment we use on CI and a real one but at the same time, we don't want to execute all the tests in the quality gate, is a way for us to determine the health of our application in a real serverless project environment.

We need a separate way of skipping tests from MKI but not CI.

A test with just @serverless is going to be executed in CI and periodic pipeline. If you add to the test @serverlessQA that test will be executed in the second quality gate as part of the release process. If a test is broken on MKI is going to fail in both on periodic and quality gate, so you can skip it with @serverlessMKI but it will still be executed on CI as part of the PRs so I strongly believe that right now what it makes sense for us to have as labels is:

@ess: Test is executed on CI ess environment @skipEss: Test is excluded fom the CI ess environment execution @serverless: Test is executed on CI serverless and periodic pipeline (MKI environment) @serverlessQA: Test is executed as part of the release process on the second quality gate which is the QA environment (MKI environment) @skipServerlessMKI: Test is excluded from being executed in any MKI environment, meaning, is not executed as part of the periodic pipeline and is not executed as part of the release process @skipServerless: Tests is excluded from being executed as part from the CI and is not executed in any MKI environment

@MadameSheema Your proposal works for me 👍

Above proposal looks great to me @MadameSheema

@MadameSheema

Me and @banderror discussed the approach on a zoom call. Tags you suggest in the last comment look good to me. I have some comments though

ESS tags are pretty clear. We need to run tests against ESS env and skip broken tests.

@ess

@skipEss

Serverless in general is pretty clear as well. We need to run test against Serverless env (abstractly it doesn't matter which one) and skip broken tests

@serverless

@skipServerless

If we don't need to run tests against some env an appropriate tag @ess or @serverless isn't added.

The most interesting part start from the fact that Serverless envs are different. Not all tests work in Serverless MKI env currently. Taking into account this fact we need an ability to skip such tests so we can use the following tag

@skipServerlessMKI

And the last part is that we need some test to block Serverless release when critical functionality doesn't work. In this case something explicit like @blockServerlessRelease or @serverlessRelease would work the best

@serverlessRelease

I have a question about your suggestion. Why do you want to use explicit @serverlessQA. Is it expected we are gonna run different test sets/subsets in QA, Staging etc Serverless MKI envs? It looks like if a test work in one Serverless MKI env it should work in the other one as well. Is there some difference between QA and Staging?

cc @rylnd

Maybe at this point it's best to jump on a Zoom. I'm a bit confused as to what's being asked here anymore.

@MadameSheema worked on this PR after we chatted and decided it'd be great for our API and cypress tags to match so this PR brought them into parity. We had discussed and decided on the tags during the first PR that changed the Cypress tags. It would be great to finalize the discussion so we don't keep rehashing the discussion in each PR.

michaelolo24

I agree with your notes here: #180773 (comment) Thank you for making these changes @MadameSheema !

MadameSheema · 2024-04-22T14:39:28Z

/ci

kibana-ci · 2024-04-22T15:55:57Z

💛 Build succeeded, but was flaky

Buildkite Build
Commit: 0ac31e6

Failed CI Steps

Metrics [docs]

✅ unchanged

History

💚 Build #204595 succeeded 78760a6
💔 Build #204582 failed 6ff7457
💚 Build #204386 succeeded 37d3b3a
💛 Build #203944 was flaky 3980615
💚 Build #203808 succeeded b052b7f
💚 Build #203631 succeeded 08b8ebc

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @MadameSheema

banderror

Thank you for addressing my concern @MadameSheema, LGTM 👍

Could we please have the same set of tags for Cypress tests?

banderror · 2024-04-23T16:06:14Z

x-pack/test/security_solution_api_integration/README.md

+- We are using the following tags:
+   * `@ess`: Runs in an ESS environment (on-prem installation) as part of the CI validation on PRs.
+
+   * `@serverless`: Runs in the first quality gate and in the periodic pipeline.


++ to @rylnd's comment

…80773) Continues elastic#179737 effort we are aligning the tags on Cypress and API to have a unified experience. ## Summary We want to start integrating our Cypress tests with the serverless Kibana quality gate. However, not all the teams feel comfortable enabling all the tests, to facilitate the effort of enabling tests in the quality gate we are adding the `@serverlessQA` tag, now on API tests as well. We use tags to select which tests we want to execute on each environment and pipeline. `ess` - runs in ESS env `serverless` - runs in serverless env and periodic pipeline (failures don't block release) `serverlessQA` - runs in kibana release process (failures block release) `skipInEss` - skipped for ESS env `skipInServerless` - skipped for all serverless related environments `skipInServerlessMKI` - skipped for MKI environments ### Description **Tests tagged as `@serverless`** All the tests tagged as `@serverless` will be executed as part of the PR validation process using the serverless FTR environment (not a real one). That tests will be executed as well as part of the periodic pipeline using a real serverless project. QA environment is used to do so using the latest available commit in main at the time of the execution. **Tests tagged as `@serverlessQA`** All the tests tagged as `@serverlessQA` will be executed as part of the kibana release process using a real serverless project with the latest image available in the QA environment **Tests tagged as `@ess`** All the tests tagged as `@ess` will be executed as part of the PR validation process using an on-prem ESS environment. **Tests tagged as `@skipInServerless`** All the tests tagged as `@skipInServerless` will be excluded from the PR validation process using the serverless FTR environment, the periodic pipeline and kibana release process for Serverless. **Tests tagged as `@skipInEss`** All the tests tagged as `skipInEss` will be excluded from the PR validation process using an on-prem ESS environment. --------- Co-authored-by: Ryland Herrick <[email protected]> (cherry picked from commit c351e14)

kibanamachine · 2024-04-23T16:25:38Z

💚 All backports created successfully

Status	Branch	Result
✅	8.14

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation

…80773) (#181468) # Backport This will backport the following commits from `main` to `8.14`: - [[Security Solution] Adds serverlessQA tag to the API tests (#180773)](#180773)  ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport)  Co-authored-by: Gloria Hornero <[email protected]>

Following up from #180773 ## Summary In this PR we are introducing the `@skipServerlessMKI` label, with it, a test will be excluded from the execution on any MKI environment but it will be executed as part of the CI check if the `@serverless` tag is present. With the new changes the serverless labels will work as follows: * `@serverless`: The test is executed as part of the PR check process and in the periodic pipeline (MKI environment). * `@serverlessQA`: The test is executed as part of the kibana release process in the QA environment (MKI environment). * `@skipInServerless`: The test is skipped from being executed in CI as part of the PR check and is skipped from being executed in any MKI environment. `@skipInServerlessMKI`: The test is skipped from being executed in any MKI environment but it will continue being executed as part of the PR process if the `@serverless` tag is present. **IMPORTANT:** The skip labels have been created for those tests that use `@serverless` or `@serverlessQA` labels. The absence of them (`@serverless` or `@serverlessQA`) will exclude automatically the execution of the test in the targeted environments. I.E: A test without `@serverlessQA` will never be executed as part of the Kibana release process. A test without `@serverless` will never be executed as part of the PR CI check neither the periodic pipeline.

Following up from elastic#180773 ## Summary In this PR we are introducing the `@skipServerlessMKI` label, with it, a test will be excluded from the execution on any MKI environment but it will be executed as part of the CI check if the `@serverless` tag is present. With the new changes the serverless labels will work as follows: * `@serverless`: The test is executed as part of the PR check process and in the periodic pipeline (MKI environment). * `@serverlessQA`: The test is executed as part of the kibana release process in the QA environment (MKI environment). * `@skipInServerless`: The test is skipped from being executed in CI as part of the PR check and is skipped from being executed in any MKI environment. `@skipInServerlessMKI`: The test is skipped from being executed in any MKI environment but it will continue being executed as part of the PR process if the `@serverless` tag is present. **IMPORTANT:** The skip labels have been created for those tests that use `@serverless` or `@serverlessQA` labels. The absence of them (`@serverless` or `@serverlessQA`) will exclude automatically the execution of the test in the targeted environments. I.E: A test without `@serverlessQA` will never be executed as part of the Kibana release process. A test without `@serverless` will never be executed as part of the PR CI check neither the periodic pipeline. (cherry picked from commit 37d47da)

# Backport This will backport the following commits from `main` to `8.14`: - [[Security Solution] Labels adjustments (#181371)](#181371)  ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport)  Co-authored-by: Gloria Hornero <[email protected]>

MadameSheema added 2 commits April 15, 2024 10:41

adds serverlessQA tag to API tests

973d5da

aling tags with Cypress tests

ec2c07b

Merge branch 'main' into api/serverlessQA

77fa125

MadameSheema added release_note:skip Skip the PR/issue when compiling release notes Team: SecuritySolution Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc. v8.14.0 labels Apr 15, 2024

MadameSheema self-assigned this Apr 15, 2024

MadameSheema marked this pull request as ready for review April 15, 2024 10:22

MadameSheema requested review from a team as code owners April 15, 2024 10:22

MadameSheema requested review from hop-dev, rylnd and nikitaindik April 15, 2024 10:22

hop-dev approved these changes Apr 15, 2024

View reviewed changes

Merge branch 'main' into api/serverlessQA

08b8ebc

spong approved these changes Apr 15, 2024

View reviewed changes

adds missing file

b052b7f

Ikuni17 approved these changes Apr 16, 2024

View reviewed changes

fixes

dae1ce9

more fixes

2137e9e

Merge branch 'main' into api/serverlessQA

37d3b3a

rylnd approved these changes Apr 17, 2024

View reviewed changes

MadameSheema and others added 4 commits April 18, 2024 10:52

Update .buildkite/pipelines/security_solution/api_integration_serverl…

cfdaefb

…ess_release.yml Co-authored-by: Ryland Herrick <[email protected]>

Update x-pack/test/security_solution_api_integration/README.md

dc14e41

Co-authored-by: Ryland Herrick <[email protected]>

Update .buildkite/pipelines/security_solution/api_integration_serverl…

6ff7457

…ess_release.yml Co-authored-by: Ryland Herrick <[email protected]>

Merge branch 'main' into api/serverlessQA

78760a6

banderror requested changes Apr 18, 2024

View reviewed changes

michaelolo24 approved these changes Apr 18, 2024

View reviewed changes

MadameSheema added 4 commits April 22, 2024 16:05

updates readme

1a6dc9a

updates package.json

7dae577

updating tags

3e1dd97

Merge branch 'main' into api/serverlessQA

0ac31e6

MadameSheema mentioned this pull request Apr 23, 2024

[Security Solution] Labels adjustments #181371

Merged

dkirchan approved these changes Apr 23, 2024

View reviewed changes

banderror approved these changes Apr 23, 2024

View reviewed changes

MadameSheema merged commit c351e14 into elastic:main Apr 23, 2024
20 checks passed

MadameSheema deleted the api/serverlessQA branch April 23, 2024 16:21

kibanamachine added the v8.15.0 label Apr 23, 2024

kibanamachine mentioned this pull request Apr 23, 2024

[8.14] [Security Solution] Adds serverlessQA tag to the API tests (#180773) #181468

Merged

mgiota mentioned this pull request May 27, 2024

[Observability solution] [SLO] Run burn rate api tests in serverless & ess using mocha tagging #183113

Closed

4 tasks

szaffarano mentioned this pull request Jul 12, 2024

[8.14] [Telemetry][Security Solution] Use the proper index to query builtin alerts (#187859) #188233

Closed


		* `@serverless`: Runs in the first quality gate and in the periodic pipeline.

		* `@serverlessQA`: Runs in the second quality gate.

[Security Solution] Adds serverlessQA tag to the API tests #180773

[Security Solution] Adds serverlessQA tag to the API tests #180773

Conversation

MadameSheema commented Apr 15, 2024 • edited by kibanamachine Loading

Summary

Description

MadameSheema commented Apr 15, 2024

elasticmachine commented Apr 15, 2024

hop-dev left a comment

Choose a reason for hiding this comment

MadameSheema commented Apr 15, 2024

spong left a comment

Choose a reason for hiding this comment

MadameSheema commented Apr 15, 2024

MadameSheema commented Apr 16, 2024

MadameSheema commented Apr 17, 2024

rylnd left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

banderror Apr 18, 2024 • edited Loading

Choose a reason for hiding this comment

MadameSheema Apr 18, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

banderror Apr 18, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MadameSheema Apr 18, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

michaelolo24 left a comment

Choose a reason for hiding this comment

MadameSheema commented Apr 22, 2024

kibana-ci commented Apr 22, 2024

💛 Build succeeded, but was flaky

Failed CI Steps

Metrics [docs]

History

banderror left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kibanamachine commented Apr 23, 2024

💚 All backports created successfully

Questions ?

MadameSheema commented Apr 15, 2024 •

edited by kibanamachine

Loading

banderror Apr 18, 2024 •

edited

Loading

MadameSheema Apr 18, 2024 •

edited

Loading

banderror Apr 18, 2024 •

edited

Loading

MadameSheema Apr 18, 2024 •

edited

Loading