[Uptime] Port functional tests to 7.x #29398
Conversation
* Add API functional tests for uptime graphQL. * Remove obsolete code. * Add CI group for UI functional tests. * Delete obsolete code, rename heartbeat es archive. * Refactor adapter methods. * Refactor adapter methods. * Attempt to fix ci-group tag error. * Skip functional app tests until later PR. * Remove unused code. * Optimize test runs. * Add uptime to api test index. * Fix formatting.
…ch_monitors_adapter.ts Implement PR feedback. Co-Authored-By: justinkambic <[email protected]>
💔 Build Failed |
💚 Build Succeeded |
💚 Build Succeeded |
| return latestMonitors; | ||
|
|
||
| // @ts-ignore undefined entries are filtered out | ||
| return latestMonitors.filter(monitor => monitor !== undefined); |
There was a problem hiding this comment.
One thought, instead of assigning latestMonitors, just chain the filter there directly, and avoid the messiness of the Array<LatestMonitor | undefined> type.
There was a problem hiding this comment.
It's funny - that's how I originally wrote it, but my IDE's linter kept complaining. I went back and re-introduced it like you suggested and it has no problem with it now. Glad you commented here, it's much cleaner now.
There was a problem hiding this comment.
Addressed in 8856be8.
x-pack/plugins/uptime/server/lib/adapters/pings/elasticsearch_pings_adapter.ts
Show resolved
Hide resolved
| @@ -9,11 +9,15 @@ import { get, set } from 'lodash'; | |||
| export const getFilteredQuery = ( | |||
| dateRangeStart: string, | |||
| dateRangeEnd: string, | |||
| filters?: string | null | |||
| filters?: string | null | any | |||
There was a problem hiding this comment.
Maybe I'm missing something here for typescript, but what's the point of keeping the string | null if we have any?
There was a problem hiding this comment.
It feels to me like the real fix here (that can happen in a subsequent PR), is to remove filters as a query param, and create a tighter API definition.
There was a problem hiding this comment.
Hm - I don't know that we actually need any defined there. Good find. I will look into it.
There was a problem hiding this comment.
We do need any (or a more specific type at least, because the function handles multiple object types) for now, but like you say, we will eventually be able to refactor and delete this code. When we implement #29745 we won't need any.. anymore. When we update the GQL schema, we can use the type we generate from that.
x-pack/plugins/uptime/server/lib/helper/get_filtered_query_and_status.ts
Show resolved
Hide resolved
|
jenkins test this |
💔 Build Failed |
💔 Build Failed |
💔 Build Failed |
💚 Build Succeeded |
Summary
We added functional tests for
6.xin #29128. This is a port of those tests. We can't use the same tests for each because of breaking HB doc changes between6.xand7.x.