[ES|QL] Validation tests agains Elasticsearch #270445
Conversation
|
/ci |
|
Caution Review failedAn error occurred during the review process. Please try again later. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 similar comment
|
Caution Review failedAn error occurred during the review process. Please try again later. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
a79793e to
1b3af55
Compare
|
/ci |
|
/ci |
|
/ci |
|
/ci |
9839573 to
6e8e64c
Compare
|
/ci |
|
I'm not closing this task yet because I still have a couple of open points to clarify:
|
|
Pinging @elastic/kibana-esql (Team:ESQL) |
stratoula
left a comment
There was a problem hiding this comment.
@bartoval we also have these src/platform/test/api_integration/apis/esql so having some there and the other here is a bit confusing.
I suggest to have one place to put the integration tests and a common testing strategy. Can you take a look holistically?
|
| await esqlEnv.setupIndicesPolicies(); | ||
| }); | ||
|
|
||
| afterAll(async () => { |
There was a problem hiding this comment.
afterAll(async () => {
try {
await esqlEnv?.cleanup();
} finally {
await esqlEnv?.integrationEnv.stop();
}
});
| if (type === 'cartesian_shape') { | ||
| esType = 'shape'; | ||
| } | ||
| if (type === 'aggregate_metric_double') { |
There was a problem hiding this comment.
Is this ok to map it as double? It is an object https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/aggregate-metric-double
| { ignore: [404] } | ||
| ); | ||
| for (const policy of policies) { | ||
| await es.enrich.deletePolicy({ name: policy.name }, { ignore: [404] }); |
There was a problem hiding this comment.
We are deleting the policies but not the backing indices.
| // Integration suites use this hook to compare the same validation run with ES. | ||
| // Unit suites leave it undefined, so their behavior stays unchanged. | ||
| const promise = validateQuery(query, cb).then(async (result) => { | ||
| await afterValidate?.({ |
There was a problem hiding this comment.
I think we need to do some optimizations before merging this Val. With all the efforts done to improve the CI time I am afraid that having these run in every PR might make the situation worse especially when we run this sequentially.
Some ideas:
- Batch the ES queries
- Only check queries with non-syntax errors
💛 Build succeeded, but was flaky
Failed CI StepsTest Failures
Metrics [docs]
History
cc @bartoval |
|
My bad Valerio, I got confused from one comment and thought we are not doing this
I didnt run them, from the code review it seems as doing this sequentially will make CI slower (?) So if we could batch them and make it even faster would be great. Unless the @elastic/appex-qa is ok with it. Not sure which is the process here but I wouldnt want to have complains about us making the CI slower in each PR 😅 |
Summary
Part of #218936
I kept the logic intentionally basic— there’s no file autodetection or other “smart” behavior.
To test it locally: