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

Standardized config property for devservices participating in container reuse #25474

Open
knutwannheden opened this issue May 10, 2022 · 3 comments
Labels

Comments

@knutwannheden
Copy link
Contributor

Description

As of #25367 Quarkus datasource devservices will get reused when Testcontainers has been configured correspondingly (testcontainers.reuse.enable=true in ~/.testcontainers.properties).

I think it would make sense to also allow other slow-starting devservices to "participate" in this. I would thus like to propose that the standard devservices config group, which already has a few standard config properties (enabled, image-name, port, shared, service-name) is extended with a new property for container reuse. Something like reuse-enabled with a default of true. This "standard" config property would of course have to be explicitly added to all extensions providing a devservice, where it conceivably makes sense with container reuse and ultimately this would allow the developer to selectively exclude certain devservices from being reused.

Some devservices should probably either not declare this config property or possibly even set the default to false.

Implementation ideas

No response

@knutwannheden knutwannheden added the kind/enhancement New feature or request label May 10, 2022
@quarkus-bot
Copy link

quarkus-bot bot commented May 10, 2022

/cc @stuartwdouglas

@knutwannheden
Copy link
Contributor Author

/cc @Sanne

@Sanne
Copy link
Member

Sanne commented May 10, 2022

It's a great idea - no objections, but bear in mind that in several cases we're using the container definition from Testcontainers, which don't consistently allow for container reuse.
And even when they do, we'd need to override each container definition to control the flag. Might be worth the work though, we can then most likely tune other aspects more easily as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants