-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
[Proposal] Define containers as RunOptions? #1337
Comments
/cc @fermayo @tonyredondo |
Yes, I think this is in BuildKit scope. I call this a network dependency. For caching/dag this is a dependency like any other but it runs in a separate container and exposes name/ip (or tcp port/unix socket if we want to keep this simpler) to another process for discovery. The executor can also do simple socket activation for lazy loading and containers do not need to run in the same machine. I don't think there is a need for magical like this?
|
Thanks for your quick feedback! Nice to hear that. We're going to start working in a POC in a |
Hi,
Working on a PoC of a custom Buildkit frontend to execute tests of a certain git repo, we'd like to validate with you guys the idea of using containers as support of a certain
llb.State
in the Buildkit DAG.The use case would be, in this case, to run integration tests which need certain containers which run in the same network namespace and, which lifecycle, is bounded to a certain
llb.State
. (e.g. a database)A theoretically example could be this:
In this example, we're using the hypothetical new
llb.RunOption
namedllb.WithService("...")
, whichBuildkit
needs to handle before/after theExecState
of run tests was executed.Ideally,
Buildkit
is using executors to start/stop containers now, so the idea would be iterate this logic to include somehow this new capability.So, our questions would be:
Buildkit
?Buildkit
for you?Thank you very much!
The text was updated successfully, but these errors were encountered: