-
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
[FTR] Merge Alerting Apis from x-pack/test_serverless/shared
into x-pack/test/api_integration/deployment_agnostic
#193975
Conversation
/ci |
@dmlemeshko |
3e51500
to
6848c6d
Compare
async findRule(ruleId: string, roleAuthc: RoleCredentials) { | ||
async findRuleInRules(roleAuthc: RoleCredentials, ruleId: string) { | ||
const response = await supertestWithoutAuth | ||
.get('/api/alerting/rules/_find') | ||
.set(roleAuthc.apiKeyHeader) |
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 a bit confused by the naming, but I saw there is another findRule
function and I think it was confusing initially.
Since you anyways work on the service, what do you think about the following:
findRule -> findRuleById(ruleId: string, roleAuthc: RoleCredentials)
when /api/alerting/rule/${ruleId}
is used in API call
findRule -> findInRules(ruleId: string, roleAuthc: RoleCredentials) (or findInAllRules
)
when /api/alerting/rules/_find
is used in API call and later we filter response
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.
Yeah there were two originally, due to merging the helpers
It's like the helpers were quickly made, instead of doing what we are doing now: discussing where they fit best, not just fit...good enough to compile and run
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.
@@ -8,12 +8,12 @@ | |||
import _ from 'lodash'; | |||
|
|||
import { services as apiIntegrationServices } from '@kbn/test-suites-xpack/api_integration/services'; | |||
import { AlertingApiProvider } from './alerting_api'; | |||
import { services as apiIntegrationDeploymentAgnosticServices } from '@kbn/test-suites-xpack/api_integration/deployment_agnostic/services'; |
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.
Do we want load all the deployment-agnostic
services or only AlertingApiProvider
?
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.
Glad you caught this.
I took the risk when I did to see if it would pass all the tests.
That said, I do not mind merging it with less risk.
What do you think?
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.
Well, I can quickly see a conflict with the same service sloApi
already existing in serverless.
It is really hard to find which service file was loaded, so I suggest explicitly picking only the ones that we need for particular PR. Ideally we can revisit it when more tests are migrated to deployment-agnostic format and "remove" duplicated services, but I would anyway keep importing explicitly 1 by 1 to speedup debug process
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.
Ahh, I like that. Will do
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.
plus folks might update sloApi
in test_serverless, but FTR will still pickup deployment-agnostic version of it. Or the opposite, it depends on lines order :)
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.
yeah, that sounds like smth we should fix.
This is not the PR for it, but constantly re-exporting * from abc
is prolly not the best for visibility.
If it's not great for us, it's gonna be worse for others
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.
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.
obs-ux-management changes LGTM
@elasticmachine merge upstream |
findRule -> findRuleById && findRule -> findInRules
@dmlemeshko ok it's looking good with all the cypress tests passing as well. Anything else you can think of here before merging? |
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.
Code changes LGTM
💛 Build succeeded, but was flaky
Failed CI StepsTest FailuresMetrics [docs]
History
To update your PR or re-run it, just comment with: |
Starting backport for target branches: 8.x |
Starting backport for target branches: 8.x |
💔 All backports failed
Manual backportTo create the backport manually run:
Questions ?Please refer to the Backport tool documentation |
💔 All backports failed
Manual backportTo create the backport manually run:
Questions ?Please refer to the Backport tool documentation |
💚 All backports created successfully
Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
…x-pack/test/api_integration/deployment_agnostic` (elastic#193975) ## Summary Follow up of [this pr](elastic#192216), per [this discussion](elastic#192216 (comment)). Also, switch from `svlCommonApi` to `samlAuth` for internal headers. --------- Co-authored-by: Elastic Machine <[email protected]> Co-authored-by: Dzmitry Lemechko <[email protected]> (cherry picked from commit 10c3373) # Conflicts: # x-pack/test_serverless/shared/services/alerting_api.ts
…into `x-pack/test/api_integration/deployment_agnostic` (#193975) (#197822) # Backport This will backport the following commits from `main` to `8.x`: - [[FTR] Merge Alerting Apis from `x-pack/test_serverless/shared` into `x-pack/test/api_integration/deployment_agnostic` (#193975)](#193975) <!--- Backport version: 8.9.8 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT [{"author":{"name":"Tre","email":"[email protected]"},"sourceCommit":{"committedDate":"2024-09-30T09:41:22Z","message":"[FTR] Merge Alerting Apis from `x-pack/test_serverless/shared` into `x-pack/test/api_integration/deployment_agnostic` (#193975)\n\n## Summary\r\n\r\nFollow up of [this pr](https://github.com/elastic/kibana/pull/192216),\r\nper [this\r\ndiscussion](https://github.com/elastic/kibana/pull/192216#discussion_r1760894369).\r\n\r\nAlso, switch from `svlCommonApi` to `samlAuth` for internal headers.\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine <[email protected]>\r\nCo-authored-by: Dzmitry Lemechko <[email protected]>","sha":"10c337387485d77fd264c11888b2c28131ee515a","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","v9.0.0","ci:all-cypress-suites","backport:prev-minor","FTR"],"number":193975,"url":"https://github.com/elastic/kibana/pull/193975","mergeCommit":{"message":"[FTR] Merge Alerting Apis from `x-pack/test_serverless/shared` into `x-pack/test/api_integration/deployment_agnostic` (#193975)\n\n## Summary\r\n\r\nFollow up of [this pr](https://github.com/elastic/kibana/pull/192216),\r\nper [this\r\ndiscussion](https://github.com/elastic/kibana/pull/192216#discussion_r1760894369).\r\n\r\nAlso, switch from `svlCommonApi` to `samlAuth` for internal headers.\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine <[email protected]>\r\nCo-authored-by: Dzmitry Lemechko <[email protected]>","sha":"10c337387485d77fd264c11888b2c28131ee515a"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","labelRegex":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/193975","number":193975,"mergeCommit":{"message":"[FTR] Merge Alerting Apis from `x-pack/test_serverless/shared` into `x-pack/test/api_integration/deployment_agnostic` (#193975)\n\n## Summary\r\n\r\nFollow up of [this pr](https://github.com/elastic/kibana/pull/192216),\r\nper [this\r\ndiscussion](https://github.com/elastic/kibana/pull/192216#discussion_r1760894369).\r\n\r\nAlso, switch from `svlCommonApi` to `samlAuth` for internal headers.\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine <[email protected]>\r\nCo-authored-by: Dzmitry Lemechko <[email protected]>","sha":"10c337387485d77fd264c11888b2c28131ee515a"}}]}] BACKPORT-->
…x-pack/test/api_integration/deployment_agnostic` (elastic#193975) Follow up of [this pr](elastic#192216), per [this discussion](elastic#192216 (comment)). Also, switch from `svlCommonApi` to `samlAuth` for internal headers. --------- Co-authored-by: Elastic Machine <[email protected]> Co-authored-by: Dzmitry Lemechko <[email protected]> (cherry picked from commit 10c3373)
Summary
Follow up of this pr, per this discussion.
Also, switch from
svlCommonApi
tosamlAuth
for internal headers.