libcompose
libcompose copied to clipboard
Support parsing additional compose fields
We use an extended compose format with additional, unsupported fields. We'd like to be able to pass in a compose file structure with our extended syntax, and provide libcompose a means to deal with these extra fields, and an extended version of the json schema. This way we could use the standard libcompose initializer, and have libcompose pass us back values loaded for custom fields.
I'm imagining something like this:
type ProjectConfigurer interface {
JsonSchema() string
ExtendedField(jsonPath string, value interface{})
}
project, err := docker.NewExtendedProject(&docker.Context{
Context: project.Context{
ComposeFiles: []string{"docker-compose.yml"},
ProjectName: "my-compose",
},
},
myProjectConfigurer,
nil)
What do you think?
Being able to use a custom schema would be great. I'm going to take a look at v2 validation soon, so I might refactor the way schemas are loaded to make it more customizable at the same time. I don't think anything other than this is strictly necessary since custom fields can just be read outside of libcompose.
+1 for this. Would it make the most sense to add a custom schema field to ParseOptions
, given that those options are already passed to docker.NewProject
along with the context? It seems logical to keep all parsing/validation logic in the same place. @joshwget if you haven't started yet, I'm happy to take a stab at this as we need support for custom fields soon-ish. Ideally this would makes switching between V1 and V2 easier as well (though I'm not totally sure how this impacts the Merge
functions).
After some more thought (and discussion with @aanand), libcompose shouldn't encourage users from using a syntax other than vanilla Docker Compose syntax. If a project using libcompose is dependent on a custom syntax, it's up to that project to store the additional fields and parse/validate them appropriately outside of the compose project itself.