-
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
[Detections Response][FTR] Move remaining basic license FTRs to new folder #172132
Conversation
.../test_suites/detections_response/basic_essentials_license/rule_import_export/import_rules.ts
Outdated
Show resolved
Hide resolved
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.
Please adjust the CodeOwners list to align with the recent modifications, as well as this document for the new groups and execution time in different environments, thanks!
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.
LGTM! thanks Yara!!
I updated the document regarding the groups but the execution time is still missing |
Pinging @elastic/security-detections-response (Team:Detections and Resp) |
Pinging @elastic/security-threat-hunting (Team:Threat Hunting) |
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.
ftr_configs.yml
@elasticmachine merge upstream |
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 had a few comments about the naming/description/categorization of these tests, but those are mostly DX optimizations and don't need to block here.
Any test changes were consistent and clear.
LGTM!
"lists_items:server:ess": "npm run initialize-server:lists:default lists_items ess", | ||
"lists_items:runner:ess": "npm run run-tests:lists:default lists_items ess essEnv" | ||
|
||
"alerts_essentials:server:serverless": "npm run initialize-server:dr:basicEssentials alerts serverless", |
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.
IMO it would be less confusing to split up the suite name from the license, but maybe there's a reason for that?
"alerts_essentials:server:serverless": "npm run initialize-server:dr:basicEssentials alerts serverless", | |
"alerts:essentials:server:serverless": "npm run initialize-server:dr:basicEssentials alerts serverless", |
loadTestFile(require.resolve('./alerts/open_close_alerts')); | ||
loadTestFile(require.resolve('./alerts/query_alerts')); | ||
loadTestFile(require.resolve('./alerts/query_alerts_backword_compatibility')); | ||
describe('Detection alerts Basic and Essentials API', function () { |
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.
Similar to my above comment about keeping that taxonomy in these names:
describe('Detection alerts Basic and Essentials API', function () { | |
describe('Detection Engine - Alerts API - Basic and Essentials', function () { |
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 suggestion. I find the naming of all our pipelines, steps, JUnit reports etc not hierarchical enough to be able to understand quickly (under 1 sec) what every name actually means, so I have to read each name carefully and "parse" it.
This could be improved in follow-up PRs, of course, not a blocker from my side.
...functionalConfig.getAll(), | ||
testFiles: [require.resolve('..')], | ||
junit: { | ||
reportName: 'Rule creation ESS - Basic Integration Tests', |
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'm trying to recall the context in which this string is presented, but my question is similar to above: should we just fully-qualify these report names so that they're easier to find/correlate?
reportName: 'Rule creation ESS - Basic Integration Tests', | |
reportName: 'Detection Engine - Rule Creation Integration Tests - ESS Env - Basic and Essential License ', |
|
||
describe('create_rules_bulk', () => { | ||
// TODO: add a new service |
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.
It's not clear to me what this comment means; I think we need more context here if we want this comment to persist/be useful
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.
@yctercero Thank you so much for moving Rule Management tests for us to the new folder. The PR is huge. I haven't scanned all the diffs in every single file that was changed, but I reviewed the overall structure.
Posting a few comments + agree with the comments that @rylnd left.
/x-pack/test/security_solution_api_integration/test_suites/detections_response/basic_essentials_license/rule_read @elastic/security-detection-rule-management | ||
/x-pack/test/security_solution_api_integration/test_suites/detections_response/basic_essentials_license/rule_management @elastic/security-detection-rule-management | ||
/x-pack/test/security_solution_api_integration/test_suites/detections_response/basic_essentials_license/rule_import_export @elastic/security-detection-rule-management |
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.
Could you also add x-pack/test/security_solution_api_integration/test_suites/detections_response/basic_essentials_license/rule_delete
here?
/x-pack/test/security_solution_api_integration/test_suites/detections_response/basic_essentials_license/rule_creation @elastic/security-detection-engine | ||
/x-pack/test/security_solution_api_integration/test_suites/detections_response/basic_essentials_license/rule_edit @elastic/security-detection-engine |
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 I might agree that although the corresponding endpoints are owned by Rule Management, the Detection Engine team should probably own integration tests for rule creation and editing. Or at least some of these tests - those related to specific rule types and parameters.
I'm just wondering what is your reasoning behind this, could you please elaborate?
loadTestFile(require.resolve('./alerts/open_close_alerts')); | ||
loadTestFile(require.resolve('./alerts/query_alerts')); | ||
loadTestFile(require.resolve('./alerts/query_alerts_backword_compatibility')); | ||
describe('Detection alerts Basic and Essentials API', function () { |
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 suggestion. I find the naming of all our pipelines, steps, JUnit reports etc not hierarchical enough to be able to understand quickly (under 1 sec) what every name actually means, so I have to read each name carefully and "parse" it.
This could be improved in follow-up PRs, of course, not a blocker from my side.
it('should return a "403 forbidden" using a rule_id of type "machine learning"', async () => { | ||
await createRule(supertest, log, getSimpleRule('rule-1')); | ||
|
||
// patch a simple rule's type to machine learning | ||
const { body } = await supertest | ||
.patch(DETECTION_ENGINE_RULES_URL) | ||
.set('kbn-xsrf', 'true') | ||
.set('elastic-api-version', '2023-10-31') | ||
.send({ rule_id: 'rule-1', type: 'machine_learning' }) | ||
.expect(403); | ||
|
||
expect(body).to.eql({ | ||
message: 'Your license does not support machine learning. Please upgrade your license.', | ||
status_code: 403, | ||
}); | ||
}); |
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.
Did you intentionally delete the test?
@banderror are you ok with me merging this one along with https://github.com/elastic/kibana/issues?q=author%3AWafaaNasr and then following up with all the comments? |
💔 Build FailedFailed CI Steps
Metrics [docs]
History
To update your PR or re-run it, just comment with: cc @yctercero |
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.
@banderror are you ok with me merging this one along with https://github.com/elastic/kibana/issues?q=author%3AWafaaNasr and then following up with all the comments?
Sure @yctercero. CI is not happy though
Yea, I am going to close this PR as it has gotten too messy. I'll reopen a smaller PR that addresses the existing comments here @rylnd . |
Summary
Files moved from old structure to new folders
detection_engine_api_integration
security_solution_api_integration
/basic/tests/create_rules_bulk.ts
/test_suites/detections_response/basic_essentials_license/rule_creation/
/basic/tests/delete_rules.ts
/test_suites/detections_response/basic_essentials_license/rule_delete/
/basic/tests/delete_rules_bulk.ts
/test_suites/detections_response/basic_essentials_license/rule_delete/
/basic/tests/patch_rules.ts
/test_suites/detections_response/basic_essentials_license/rule_edit/
/basic/tests/patch_rules_rules_bulk.ts
/test_suites/detections_response/basic_essentials_license/rule_edit/
/basic/tests/update_rules.ts
/test_suites/detections_response/basic_essentials_license/rule_edit/
/basic/tests/update_rules_bulk.ts
/test_suites/detections_response/basic_essentials_license/rule_edit/
/basic/tests/import_rules.ts
/test_suites/detections_response/basic_essentials_license/rule_import_export/
/basic/tests/export_rules.ts
/test_suites/detections_response/basic_essentials_license/rule_import_export/
/basic/tests/coverate_overview.ts
/test_suites/detections_response/basic_essentials_license/rule_management/
/basic/tests/find_rules.ts
/test_suites/detections_response/basic_essentials_license/rule_read/
/basic/tests/read_rules.ts
/test_suites/detections_response/basic_essentials_license/rule_read/
detection_engine_api_integration
timeline
/basic/tests/import_timelines.ts
/security_and_spaces/tests/basic/import_timelines.ts
/basic/tests/install_prepackaged_timelines.ts
/timeline/security_and_spaces/tests/basic/install_prepackaged_timelines.ts
Folders renamed
x-pack/test/security_solution_api_integration/test_suites/lists_and_exception_lists/
-->x-pack/test/security_solution_api_integration/test_suites/value_lists_and_exception_lists/
x-pack/test/security_solution_api_integration/test_suites/lists_and_exception_lists/default_license/exception_lists_items/
-->x-pack/test/security_solution_api_integration/test_suites/value_lists_and_exception_lists/default_license/exception_lists/
x-pack/test/security_solution_api_integration/test_suites/lists_and_exception_lists/default_license/lists_items/
-->x-pack/test/security_solution_api_integration/test_suites/value_lists_and_exception_lists/default_license/value_lists/
Test status
read_rules.ts
find_rules.ts
coverage_overview.ts
export_rules.ts
import_rules.ts
patch_rules.ts
patch_rules_bulk.ts
patch_rules_ess.ts
update_rules.ts
update_rules_ess.ts
update_rules_bulk.ts
delete_rules.ts
delete_rules_bulk.ts
create_rules_bulk.ts