Conversation
|
/ci |
|
/ci |
|
/ci |
|
/ci |
yctercero
added
release_note:skip
|
Pinging @elastic/security-detection-engine (Team:Detection Engine) |
machadoum
left a comment
machadoum
left a comment
There was a problem hiding this comment.
New entity analytics folder structure LGTM!
Thank you, Yara!
| timeout_in_minutes: 120 | ||
| retry: | ||
| automatic: | ||
| - exit_status: '1' |
There was a problem hiding this comment.
Don't want to block, makes more sense as a follow up for the whole file:
It looks like we don't have any retries for spot instance preemptions. The exit status is -1 in that case. Depending on stability requirements we can swap out spot instances or add retries.
There was a problem hiding this comment.
@MadameSheema any feedback on what the suggested value is?
jbudz
left a comment
jbudz
left a comment
There was a problem hiding this comment.
.buildkite, ftr_configs.yml
rylnd
left a comment
rylnd
left a comment
There was a problem hiding this comment.
I had some nits about whitespace and test names, but the general idea here is very straightforward and well-contained. I also perused the CODEOWNERS changes, and didn't find anything odd or out of place.
LGTM, thanks!
...test_suites/lists_and_exception_lists/lists_items/trial_license_complete_tier/lists/index.ts
Outdated
Show resolved
Hide resolved
nikitaindik
left a comment
nikitaindik
left a comment
There was a problem hiding this comment.
Thanks for reorganizing it @yctercero! Codeowner assignments look much cleaner now!
I've reviewed the rule management part. In my opinion, it's reasonable to move the patch and the update endpoints under rules management since RM owns these. Otherwise we'll need to carve out an exception for these in the codeowners file.
One thing that caught my attention is this nested "rule_management" dir at:
x-pack/test/security_solution_api_integration/test_suites/detections_response/rules_management/rule_management
A dir named "rule_management" that sits inside "rules_management" makes navigation a bit confusing. Also, the name is very generic for a domain name, which may promote dumping all kinds of tests there. I think it might make more sense to move the tests contained in the inner "rules_management" dir to the domain level above, like:
I'm sure Georgii has a strong opinion about this :), so it warrants a team discussion once he returns. Furthermore, it's out of the scope of this PR, so I approve.
💚 Build Succeeded
Metrics [docs]
History
To update your PR or re-run it, just comment with: cc @yctercero |
## Summary While it touches a large number of files, this PR is purely folder restructure. It is not intended to change any test functionality or enabled/disable any tests. Updates the D&R FTRs to follow a similar domain based folder structure like that of cypress. This should greatly simplify code owners and also allow us to quickly understand different licensing coverage by looking at the folders. Co-authored-by: Wafaa Nasr <wafaa.nasr@elastic.co>
11 participants
Summary
While it touches a large number of files, this PR is purely folder restructure. It is not intended to change any test functionality or enabled/disable any tests. Updates the D&R FTRs to follow a similar domain based folder structure like that of cypress. This should greatly simplify code owners and also allow us to quickly understand different licensing coverage by looking at the folders.
New folder structure
Example of when there are tests for multiple licenses
Open questions