-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Security Solution] Adds serverlessQA tag to the API tests #180773
Changes from all commits
973d5da
ec2c07b
77fa125
08b8ebc
b052b7f
dae1ce9
2137e9e
3980615
39270f7
0cc8b13
37d3b3a
cfdaefb
dc14e41
6ff7457
78760a6
1a6dc9a
7dae577
3e1dd97
0ac31e6
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Large diffs are not rendered by default.
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -15,16 +15,28 @@ we have introduced the `detection_response` directory to consolidate all the int | |
|
||
- In this directory, Mocha tagging is utilized to assign tags to specific test suites and individual test cases. This tagging system enables the ability to selectively apply tags to test suites and test cases, facilitating the exclusion of specific test cases within a test suite as needed. | ||
|
||
- There are three primary tags that have been defined: @ess, @serverless, and @brokenInServerless | ||
|
||
- Test suites and cases are prefixed with specific tags to determine their execution in particular environments or to exclude them from specific environments. | ||
|
||
- 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. | ||
|
||
* `@serverlessQA`: Runs in the second quality gate. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. IMO referencing the "gate order" might be the most straightforward way to express this; it's not intuitive that |
||
|
||
* `@skipInEss`: Skipped for ESS environment. | ||
|
||
* `@skipInServerless`: Skipped for all quality gates, CI and periodic pipeline. | ||
|
||
* `@skipInServerlessMKI`: Skipped for all the MKI environments. | ||
|
||
ex: | ||
``` | ||
describe('@serverless @ess create_rules', () => { ==> tests in this suite will run in both Ess and Serverless | ||
describe('creating rules', () => {}); | ||
|
||
describe('@brokenInServerless missing timestamps', () => {}); ==> tests in this suite will be excluded in Serverless | ||
// This test is skipped due to flakiness in serverless environments: https://github.com/elastic/kibana/issues/497777 | ||
describe('@skipInServerless missing timestamps', () => {}); ==> tests in this suite will be excluded in Serverless | ||
rylnd marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
``` | ||
|
||
|
@@ -86,7 +98,7 @@ In this project, you can run various commands to execute tests and workflows, ea | |
``` | ||
3. **Run tests for "exception_workflows" using the serverless runner in the "qaEnv" environment:** | ||
```shell | ||
npm run run-tests:dr:default exceptions/workflows serverless qaEnv | ||
npm run run-tests:dr:default exceptions/workflows serverless qaPeriodicEnv | ||
``` | ||
4. **Run the server for "exception_workflows" in the "essEnv" environment:** | ||
```shell | ||
|
Large diffs are not rendered by default.
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -21,15 +21,19 @@ let grepArgs = []; | |
if (type !== 'server') { | ||
switch (environment) { | ||
case 'serverlessEnv': | ||
grepArgs = ['--grep', '/^(?!.*@brokenInServerless).*@serverless.*/']; | ||
grepArgs = ['--grep', '/^(?!.*@skipInServerless).*@serverless.*/']; | ||
break; | ||
|
||
case 'essEnv': | ||
grepArgs = ['--grep', '/^(?!.*@brokenInEss).*@ess.*/']; | ||
grepArgs = ['--grep', '/^(?!.*@skipInEss).*@ess.*/']; | ||
break; | ||
|
||
case 'qaPeriodicEnv': | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do I get it right all Serverless tests besides skipped ones will run periodically against MKI env? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Exactly :) |
||
grepArgs = ['--grep', '/^(?!.*@skipInServerless|.*@skipInServerlessMKI).*@serverless.*/']; | ||
break; | ||
|
||
case 'qaEnv': | ||
grepArgs = ['--grep', '/^(?!.*@brokenInServerless|.*@skipInQA).*@serverless.*/']; | ||
grepArgs = ['--grep', '/^(?!.*@skipInServerless|.*@skipInServerlessMKI).*@serverlessQA.*/']; | ||
break; | ||
|
||
default: | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @rylnd everything is already documented.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
++ to @rylnd's comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the ideal approach in my mind would be:
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?