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

feat: allow explicitly specifying provider type #1990

Closed

Conversation

austince
Copy link

What does this PR do?

Allows explicitly setting the provider type via an environment variable or the properties file in addition to the autodetection introduced in #982

Why is it important?

Autodetection does not work in all scenarios, like when using the Podman Desktop compatibility mode since the docker host still points to the docker unix socket (which has been soft linked).

Related issues

Mentioned in #604 (comment)

@austince austince requested a review from a team as a code owner December 12, 2023 00:38
Copy link

netlify bot commented Dec 12, 2023

Deploy Preview for testcontainers-go ready!

Name Link
🔨 Latest commit 8ac6eb6
🔍 Latest deploy log https://app.netlify.com/sites/testcontainers-go/deploys/6577abe060790a0008342d35
😎 Deploy Preview https://deploy-preview-1990--testcontainers-go.netlify.app/system_requirements/using_podman
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

@austince austince force-pushed the feat/provider-type-explicit branch from 6fb035c to 8ac6eb6 Compare December 12, 2023 00:39
@mdelapenya
Copy link
Member

Hey @austince, as I commented in #1991 (reply in thread), I think we should disregard the manual configuration of the provider but instead make the existing auto-discovery mechanism to detect the provider in a more robust manner.

If you agree, I'd close this PR in favour of another one that makes the mechanism more robust, deprecating the existing non-default providers. Wdyt?

@austince
Copy link
Author

If you agree, I'd close this PR in favour of another one that makes the mechanism more robust, deprecating the existing non-default providers. Wdyt?

Would seem to make sense, though a proposal of how to do so would be good to understand what it would take\ -- what are you thinking for this one?

@godart
Copy link

godart commented Apr 18, 2024

As mentiones in #2264: Maybe using '/info/' '/version' requests to determine if Podman is used.

~> curl  --unix-socket /var/run/docker.sock "http://v1.41/version"  -s | jq '.Components'
[
  {
    "Name": "Podman Engine",
    "Version": "5.0.1",
    "Details": {
         <... snip />
    }
  },
  {
    "Name": "Conmon",
     <... snip />
  },
  {
    "Name": "OCI Runtime (crun)",
     <... snip />
  }
]

@mdelapenya
Copy link
Member

I'm working on a v1 release candidate (see https://github.com/testcontainers/testcontainers-go/tree/v1) and in there I'm removing the Provider abstraction. So I think we should close this PR.

@mdelapenya
Copy link
Member

Closing as per #1990 (comment)

Thank you so much!

@mdelapenya mdelapenya closed this Aug 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants