Skip to content

Run aggs tests in aggs module#90851

Merged
nik9000 merged 3 commits intoelastic:mainfrom
nik9000:agg_module_tests
Oct 17, 2022
Merged

Run aggs tests in aggs module#90851
nik9000 merged 3 commits intoelastic:mainfrom
nik9000:agg_module_tests

Conversation

@nik9000
Copy link
Copy Markdown
Member

@nik9000 nik9000 commented Oct 12, 2022

Run the aggregations tests v7 compat tests against the aggregations module and not the rest-api-spec module. This allows us to drop rest-api-spec's dependency on the aggregations module and keep it "just the server" which is nice.

There are a few side effects here that are ok:

  1. We run all aggregations REST tests in the aggregations module. Even the ones in rest-api-spec. This means we run them twice. We plan to move all of the aggregations REST tests into the aggregations module anyway.
  2. We now bundle the REST tests in the aggregations module into the tests that the clients run for their verification step. This should keep our clients from losing coverage.

Relates to #90283

Run the aggregations tests v7 compat tests against the aggregations
module and *not* the `rest-api-spec` module. This allows us to drop
`rest-api-spec`'s dependency on the aggregations module and keep it
"just the server" which is nice.

There are a few side effects here that are ok:
1. We run all aggregations REST tests in the aggregations module.
   Even the ones in `rest-api-spec`. This means we run them twice. We
   plan to move all of the aggregations REST tests into the aggregations
   module anyway.
2. We now bundle the REST tests in the aggregations module into the
   tests that the clients run for their verification step. This should
   keep our clients from losing coverage.
@nik9000 nik9000 added >test Issues or PRs that are addressing/adding tests :Analytics/Aggregations Aggregations v8.6.0 labels Oct 12, 2022
@nik9000 nik9000 requested review from jakelandis, mark-vieira and martijnvg and removed request for mark-vieira October 12, 2022 18:31
@elasticsearchmachine elasticsearchmachine added the Team:Analytics Meta label for analytical engine team (ESQL/Aggs/Geo) label Oct 12, 2022
@elasticsearchmachine
Copy link
Copy Markdown
Collaborator

Pinging @elastic/es-analytics-geo (Team:Analytics)

.toPath()
.resolve(RELATIVE_REST_CORE)
.resolve(RELATIVE_REST_PROJECT_RESOURCES)
.resolve(RELATIVE_TEST_PATH)
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The old path didn't exist. I could have merged the paths some more but I don't feel particularly confident working on this code. I am a little worried what'll happen when I "fix" this. Will we start running tests we hadn't been running before? CI will tell me if any of them fail at least....

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, so this was just wrong before I assume?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think so! The path didn't exist and nothing was ever copied.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed this is a bug. Fortunately it only impacts copying tests from core (includeCore) for modules that have the yaml-rest-compat-test plugin. It seems that this only impacts this aggs module.

However, while reviewing i see that we have 2 projects (enrich, watcher with security) attempting to copy some tests from xpack (includeXpack) that are not running the compat tests as they should be since the path to the x-pack tests is also wrong. I will followup on that in a different PR.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#90925 to fix the x-pack path, and #90929 to be a bit smarter here.

task.skipTest("search.aggregation/210_top_hits_nested_metric/top_hits aggregation with sequence numbers", "#42809 the use nested path and filter sort throws an exception")
task.skipTest("search.aggregation/370_doc_count_field/Test filters agg with doc_count", "Uses profiler for assertions which is not backwards compatible")

task.addAllowedWarningRegex("\\[types removal\\].*")
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These were all from the rest-api-spec module

dependencies {
apis project(path: ':rest-api-spec', configuration: 'restSpecs')
freeTests project(path: ':rest-api-spec', configuration: 'restTests')
freeTests project(path: ':modules:aggregations', configuration: 'restTests')
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The clients were going to lose tests every time we port things from rest-api-spec into the aggregations module without this.

Copy link
Copy Markdown
Member

@martijnvg martijnvg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't judge the change to YamlRestCompatTestPlugin, otherwise LGTM.

We run all aggregations REST tests in the aggregations module. Even the ones in rest-api-spec. This means we run them twice. We plan to move all of the aggregations REST tests into the aggregations module anyway.

This is a lesser concern to me, because it is temporary. Maybe we can move all core aggs yaml rest tests first in a followup change and then later move the actual aggs to the new module? I suspect most yaml tests will keep working without other changes, should just be a simple git move?

// This dependency can be removed when aggregations and
// respective yaml test have been moved to aggregations module.
// See for the progress: https://github.com/elastic/elasticsearch/issues/90283
module ':modules:aggregations'
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

Copy link
Copy Markdown
Contributor

@mark-vieira mark-vieira left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

.toPath()
.resolve(RELATIVE_REST_CORE)
.resolve(RELATIVE_REST_PROJECT_RESOURCES)
.resolve(RELATIVE_TEST_PATH)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, so this was just wrong before I assume?

Copy link
Copy Markdown
Contributor

@jakelandis jakelandis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM , thanks for fixing this.

@nik9000 nik9000 merged commit cd4116c into elastic:main Oct 17, 2022
jakelandis added a commit that referenced this pull request Oct 17, 2022
Compatible REST tests (like normal REST tests) allow copying the tests from either 
`rest-api-spec/src/yamlRestTest/resources/rest-api-spec/test` (includeCore) or 
`x-pack/plugin/src/yamlRestTest/resources/rest-api-spec/test`  (includeXpack). 
Both are currently broken.  #90851 fixes 
the former , and this commit fixes the later. The fix here is to ensure the correct 
path to the x-pack rest tests when pulling from the elder branch for compatible testing. 
This only impacts modules that have the compatibility plugin enabled and are 
configured to pull from the main x-pack  set of tests. Currently, this should only 
impact `:x-pack:plugin:enrich:qa:rest` but will fix it for future projects with that configuration.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

:Analytics/Aggregations Aggregations Team:Analytics Meta label for analytical engine team (ESQL/Aggs/Geo) >test Issues or PRs that are addressing/adding tests v8.6.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants