Migrate reporting FTRs from the Stats Usage API#151808
Conversation
bf7834b to
0654211
Compare
There was a problem hiding this comment.
adding these overrides to make it easier to consumers to deal with the output data.
There was a problem hiding this comment.
Removing the API as it not recommended for its use to fetch usage.
0654211 to
c418438
Compare
|
Pinging @elastic/kibana-core (Team:Core) |
|
Pinging @elastic/appex-sharedux (Team:SharedUX) |
| describe('server', function () { | ||
| this.tags('skipCloud'); | ||
| it('configuration settings of the tests_server', async () => { | ||
| const usage = await usageAPI.getUsageStats(); |
There was a problem hiding this comment.
I tried unskipping it, but it was still flaky. I can try to debug it on a follow up PR. I wouldn't like to delay this one further because it's blocking a community PR 🧡
tsullivan
left a comment
There was a problem hiding this comment.
x-pack/test/reporting_api_integration changes LGTM! Thanks for handling this!
| stack_stats: object; | ||
| // Needed for testing to make fields easier to access | ||
| // eslint-disable-next-line @typescript-eslint/no-explicit-any | ||
| stack_stats: Record<string, any>; |
There was a problem hiding this comment.
any is a footgun, if we want to use it to avoid real types I think we should rather cast to any in the test. Even if it means we're having to repeat it a bit more.
There was a problem hiding this comment.
I see your point! I reverted this change and specified this test-friendlier type in the FTR helper in 4c813a5 (#151808)
💚 Build Succeeded
Metrics [docs]
History
To update your PR or re-run it, just comment with: cc @afharo |
Summary
Part of #150429. To unblock #151082 we need to migrate the
reportingFTRs away from the deprecated Stats API to use the actual telemetry API.Checklist
For maintainers