-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
repository-s3 yamlRestTests to new cluster test framework #102353
repository-s3 yamlRestTests to new cluster test framework #102353
Conversation
Pinging @elastic/es-delivery (Team:Delivery) |
- Rework docker-compose fixture usages to leverage testcontainers - Support lazy evaluated system properties for local cluster definitions
4484857
to
cd9eeec
Compare
simplify fixture usage by relying on plain idiomatic gradle apis and best practices
Do not rely on docker compose for MinioFixture
test/fixtures/s3-fixture/src/main/java/fixture/s3/junit/S3HttpFixtureRule.java
Outdated
Show resolved
Hide resolved
...c/yamlRestTest/java/org/elasticsearch/repositories/s3/RepositoryS3ClientYamlTestSuiteIT.java
Outdated
Show resolved
Hide resolved
.../internalClusterTest/java/org/elasticsearch/repositories/s3/S3RepositoryThirdPartyTests.java
Outdated
Show resolved
Hide resolved
.../internalClusterTest/java/org/elasticsearch/repositories/s3/S3RepositoryThirdPartyTests.java
Outdated
Show resolved
Hide resolved
...c/yamlRestTest/java/org/elasticsearch/repositories/s3/RepositoryS3ClientYamlTestSuiteIT.java
Outdated
Show resolved
Hide resolved
test/fixtures/s3-fixture/src/main/java/fixture/s3/junit/S3HttpFixtureRule.java
Outdated
Show resolved
Hide resolved
...st-clusters/src/main/java/org/elasticsearch/test/cluster/local/AbstractLocalSpecBuilder.java
Show resolved
Hide resolved
...o-fixture/src/main/java/org/elasticsearch/test/fixtures/minio/MinioFixtureTestContainer.java
Outdated
Show resolved
Hide resolved
...c/yamlRestTest/java/org/elasticsearch/repositories/s3/RepositoryS3ClientYamlTestSuiteIT.java
Outdated
Show resolved
Hide resolved
@mark-vieira I rewrote this to split up the fixtures and simplify the build script for repository-s3 (reducing test tasks). This feels pretty nice now. Only the S3 fixtures still look a bit messy as we for now use them as TestRule and Standalone (in other s3 projects). Once we port all others we can clean that up even more imo. |
...c/yamlRestTest/java/org/elasticsearch/repositories/s3/RepositoryS3ClientYamlTestSuiteIT.java
Outdated
Show resolved
Hide resolved
systemProperty 'test.s3.account', s3PermanentAccessKey | ||
systemProperty 'test.s3.key', s3PermanentSecretKey | ||
systemProperty 'test.s3.bucket', s3PermanentBucket | ||
nonInputProperties.systemProperty 'test.s3.base', s3PermanentBasePath + "_third_party_tests_" + BuildParams.testSeed | ||
if (useFixture) { |
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.
So I think one side-effect of this is we no longer have the ability to run the third party tests against a fixture. We can only run these with a real external service. I think we should wire the test case up to still support using fixtures. This is the case in the other repository modules and is helpful for local development.
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 think this was never wired against the s3 fixtures. it just uses the minio fixture. Originally its configuration was not within that if statement: https://github.com/elastic/elasticsearch/blob/main/modules/repository-s3/build.gradle#L360C1-L375
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.
Yes, because it probably only needed the minio fixture to run. Minio is just a mock S3 implementation. You can see below I can run these tests locally. I'm pretty sure that would fail with this PR.
https://gradle-enterprise.elastic.co/s/dfnnlb42ib4wc/tests/overview
import org.elasticsearch.test.rest.yaml.ESClientYamlSuiteTestCase; | ||
|
||
public abstract class AbstractRepositoryS3ClientYamlTestSuiteIT extends ESClientYamlSuiteTestCase { | ||
static final boolean USE_FIXTURE = Booleans.parseBoolean(System.getProperty("tests.use.fixture", "true")); |
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 actually don't think we need this. We never run any tests in yamlRestTest
without a fixture. This should only be applicable to S3RepositoryThirdPartyTests
which are designed to run against a real endpoint.
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 kept it there to ensure all test behave like they did before. that is, if use fixture in the build script is declared, those tests are never executed.
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, but I don't think that makes sense for these tests. These tests never talk to a real external service. That's what the third party tests are for. I think this should exist there and not here.
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 think there's something fundamentally wrong in how these tests are designed in the first place already before this PR.
With this change they never run against third party really. only against the minio fixture. Actually I think the yamlRestTest task should run against thirdparty. I create a separate ticket to address this as this has been all wrong before this
...amlRestTest/java/org/elasticsearch/repositories/s3/RepositoryS3StsClientYamlTestSuiteIT.java
Outdated
Show resolved
Hide resolved
I left a few more minor comments but otherwise this looks great.
We should prioritize this work. |
I now understand what's going on here I think and what caused the confusion. The s3thirdpartytests are setup so they can run locally and against remote cluster. The build script setup has been done in a way that in theory you could a subset of yaml tests also against a remote service. I cleaned that up as you suggested in a follow up PR: #102454 One question is if we want to support this scenario for the yaml tests or not. Seems it worked at one point but those tests haven't been setup to run remotely at all. If we wanna ditch that support and think testing against our fixtures is enough for the yaml test suite, then we can cleanup that build script even more I think. |
We should reach out to @elastic/es-distributed on this. It's not clear to me that we ever ran those tests against a remote service. AFAIK we only ran the explicit "third party" test suite that way. |
This refactors the repository-s3 yaml rest test suite to leverage our new testing framework.
As part of that migration s3 fixture has been reworked to ship with a Junit based test fixture that allows using different s3 fixtures directly without the need of any docker virtualisation or external processes.
As part of this refactoring a MinioTestContainer was introduced that leverages TestContainer api to build a docker based test fixture without the need to rely on specific docker or a docker compose file .
In general we want to move away from relying on the docker-compose-gradle plugin as its setup is overly complex to integrate with our testfixtures handling, has proven to be error prone and flaky and it makes compliance with gradle configuration cache compatibility (see ##57918)
From here we can move forward and replace other docker compose based usages of our s3-fixture and mini-fixture in our build before cleaning up s3-fixture and mini-fixture completely
Some comparison build scans:
old: https://gradle-enterprise.elastic.co/s/xz5xu3oqqxhdc
new: https://gradle-enterprise.elastic.co/s/soa65wjpm5rr2
new with configuration cache enabled: https://gradle-enterprise.elastic.co/s/4udekkgo3vfxq/timeline