(I touched on this here too: https://github.com/apache/polaris/pull/590#discussion_r1909321366)
The desire to have support for different test environments stems from a recognition that a subset of Polaris tests are useful for validating a live deployment of Polaris. The hope is to reuse those tests as much as possible. Polaris shouldn't necessarily need to worry about how the remote tests are orchestrated, but there has to be some amount of flexibility through something like a TestEnvironmentExtension which enables many different ways of running remote tests. Best, Andrew On Mon, Jan 6, 2025 at 7:10 AM Dmitri Bourlatchkov <dmitri.bourlatch...@dremio.com.invalid> wrote: > Hi All, > > I'd like to clarify the role and intended use of TestEnvironmentExtension > in the Polaris test codebase. > > The OSS part of the code that relates to TestEnvironmentExtension does not > appear to demonstrate how non-dropwizard environments function. > > I'd appreciate it if people could share their thoughts and use cases that > rely on TestEnvironmentExtension. > > In particular, this touches on https://github.com/apache/polaris/pull/590 > > Main questions from my POV: > > 1) Are different environments expected to be configured differently for > some tests? How is the configuration communicated between tests and > servers? > > 2) How are tests expected to be executed in non-default environments? Same > gradle scripts as the main Polaris build? Some other (custom) gradle > script? JUnit5 lauchners? > > Thanks, > Dmitri. >
