Skip to content
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

Merged
merged 36 commits into from
Nov 22, 2023

Conversation

breskeby
Copy link
Contributor

@breskeby breskeby commented Nov 18, 2023

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)

  • Rework fixture-s3 fixture
  • Rework minio fixture
  • Support lazy evaluated system properties for local cluster definitions in our new test cluster framework.

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

@breskeby breskeby self-assigned this Nov 18, 2023
@breskeby breskeby added >enhancement :Delivery/Build Build or test infrastructure Team:Delivery Meta label for Delivery team labels Nov 18, 2023
@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/es-delivery (Team:Delivery)

- Rework docker-compose fixture usages to leverage testcontainers
- Support lazy evaluated system properties for local cluster definitions
@breskeby breskeby force-pushed the port-repository-s3-to-newtestframework branch from 4484857 to cd9eeec Compare November 18, 2023 22:26
@breskeby breskeby changed the title Port repository-s3 to new cluster test framework WIP - Port repository-s3 yaml-rest-test to new cluster test framework Nov 18, 2023
@breskeby breskeby changed the title repository-s3 yaml-rest-test to new cluster test framework repository-s3 yamlRestRest to new cluster test framework Nov 20, 2023
@breskeby breskeby changed the title repository-s3 yamlRestRest to new cluster test framework repository-s3 yamlRestTests to new cluster test framework Nov 20, 2023
@breskeby
Copy link
Contributor Author

@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.

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) {
Copy link
Contributor

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.

Copy link
Contributor Author

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

Copy link
Contributor

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"));
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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

build-tools-internal/version.properties Outdated Show resolved Hide resolved
@mark-vieira
Copy link
Contributor

I left a few more minor comments but otherwise this looks great.

Once we port all others we can clean that up even more imo.

We should prioritize this work.

@breskeby breskeby added auto-merge-without-approval Automatically merge pull request when CI checks pass (NB doesn't wait for reviews!) and removed auto-merge-without-approval Automatically merge pull request when CI checks pass (NB doesn't wait for reviews!) labels Nov 21, 2023
@breskeby breskeby merged commit c11315d into elastic:main Nov 22, 2023
14 checks passed
@breskeby breskeby deleted the port-repository-s3-to-newtestframework branch November 22, 2023 09:09
@breskeby
Copy link
Contributor Author

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.

@mark-vieira
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Delivery/Build Build or test infrastructure >enhancement Team:Delivery Meta label for Delivery team v8.12.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants