#Additional contexts
terse garnet
Maybe something like dag.SetContext("name-of-the-context", *dagger.Directory) ? Then in the dockerBuild add a parameter that accepts a list of BuildContext objects ?
terse garnet
do you think it would worth adding it to dockerBuild function @maiden raft ?
maiden raft
Mmmm I would love to see an example of multiple contexts in a dockerfile you're trying to migrate.
At first glance it looks like a lot of stick, and not a lot of carrot... Meaning that it might be a lot of work to add support for that, and at the same time a Dockerfile that grows complicated enough to need multiple contexts, should probably just be ported to real code..
(specifically, a function with 2 directory arguments)
Dagger itself has no need for a SetContext, you just pass 2 arguments to your function and you're done. Hell if you need a dynamic number of contexts, you can pass a whole array of directories 🙂
terse garnet
Using native dagger I agree. But with the dockerBuild function that relies on a Dockerfile that's something else... The dockerfile in question is for a php container with multi stage build. One of this stage is dedicted to php itself with its own context with ini files, .conf files and so on. And another context for source code of the application. to each context you can attach a .dockerignore and have clear separate directories to host your files.
Regarding the SetContext or another approach I was thinking of this approach because of how secrets are handled as well. See https://docs.dagger.io/getting-started/types/secret#use-secret-in-dockerfile-build .
maiden raft
Using native dagger I agree. But with the `dockerBuild` function that relies on ...
Mmmm, I wonder if that example is still a best practice? 🤔 cc @opaque wasp @undone knoll @fossil pike
I'm not up-to-date on that particular part of the API, so I don't have an informed opinion. Let's see what the experts say 🙂
One thing I can say - the shape of that API is very specific to secrets, and the fact that they already have a concept of "name" attached to them, at least in the original setSecret API (which we may be deprecating soon?)
In the case of context directories, the situation is different. If we were to add support for multi context to dockerBuild, we would probably look for another way to map names to directories
terse garnet
ok. Because as far as I understand, we can't pass an associative array through dagger arguments yet. Am I right ?
maiden raft
yes that's right. the graphql type system doesn't support it
you can have arrays of objects though. so it's more of a cosmetic issue
eg not polluting the api with ultra specialized types
terse garnet
yes. that is why I though of this SetContext (or whatever the name) because yoiu create the object beforehand and then you can pass the id right ?
otherwise I don't see (yet) how to pass objects as arguments
maiden raft
but dag.SetContext is a top level dagger function, very visual, for a very niche use case
terse garnet
fr container / directories it is simple because we can cast from a string
terse garnet
yeah definteley ! that would be nice indeed
maiden raft
fr container / directories it is simple because we can cast from a string
that's a client side convenience only, in the api itself a directory must be passed as an object
there's a special Address type for the string casting
(eg load a directory from a host path etc)
undone knoll
Additional contexts
undone knoll
Mmmm, I wonder if that example is still a best practice? 🤔 cc <@949034677610643...
yes this is best practice
there's no other way to do it - the ideal api would be a a SecretBinding or something type, that would bind a secret to a name that dockerBuild could accept.
but that doesn't exist right now
terse garnet
What if we create a DockerBuild object as suggested. Then secrets / context could be integrated directly within that object right ? Wouldn't that make things simpler ?
undone knoll
not personally a fan of increasing the scope of docker build. especially as there's a long term aim of removing the implementation from the core api, and splitting it out.
i'm just imagining an equivalent of the BuildArg type we already have today, but instead of a string value, it has a secret value
maybe BuildSecret would be a better name