Skip to content

Conversation

fxposter
Copy link

"-config" option now accepts wildcards (ie: it's processed via
go's filepath.Glob) and multiple files with ",":

docker-gen -config /example/a,/example/b,/usr/configs/*

"-config" option now accepts wildcards (ie: it's processed via
go's `filepath.Glob`) and multiple files with ",":

  docker-gen -config /example/a,/example/b,/usr/configs/*
@md5
Copy link
Contributor

md5 commented Feb 22, 2015

I'd prefer to see docker-gen accept multiple -config settings each with their own config file. If you really want to be able to use globbing, it could make sense for the shell to do the globbing and have -config take multiple arguments (greedy up until the next -param).

@fxposter
Copy link
Author

Actually, globbing is the first step in the direction I'd like to have - so that multiple application provide templates and configs to single docker-gen instance and so that docker-gen automatically catch file changes and filelist changes and regenerate templates based on new configs/

@md5
Copy link
Contributor

md5 commented Feb 22, 2015

I'm just not a fan of utilities doing their own glob processing of command-line arguments if it can be avoided.

As for docker-gen regenerating templates based on new configs, I don't think you could do that with globs anyways since docker-gen doesn't watch config files for changes. If a directory-based approach were taken, docker-gen could potentially use inotify to watch for config file changes (at least on Linux), but there no way to register an inotify watch for a glob that I'm aware of.

@fxposter
Copy link
Author

You could just poll on selected interval for anything ;)

@md5
Copy link
Contributor

md5 commented May 4, 2015

I just opened an alternate PR at #84 that supports passing the -config flag multiple times to specify multiple config files. I didn't add the globbing because of the complications I mentioned before, but I think the globbing is orthogonal to supporting multiple config files.

@jwilder
Copy link
Collaborator

jwilder commented May 4, 2015

Closing this in favor of #84.

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