@sdurrheimer env and labels are for json-file, journald, gelf and fluentd. For tags, I'm not sure 😅.

Hm, I'll have to check as well. I wonder if we should just "assume" a driver supports all non-namespaced options (I.e. the options that are not prefixed with the driver-name), and make it a responsibility of the user to read the docs to check if the driver supports the flag (if a driver doesn't support it, will it silently be ignored). I can imagine all these options are a nightmare to maintain in the completions

I wonder if we should just "assume" a driver supports all non-namespaced options

let's assume that in the completion, it will make our lives much easier.

Do we agree on making env labels and tag global log options in zsh completion even if those options are not necessarily used by all log drivers ?

@sdurrheimer sgtm, I think that'd make it a lot easier to maintain

@sdurrheimer @thaJeztah It really depends if those flags are ignored or if they make the command fail 😅 .

In bash completion, these options are not global: https://github.com/docker/docker/blob/master/contrib/completion/bash/docker#L331-L337.
(I'm not sure if this matrix is really correct, though.)

This makes me wonder whether both completions have to behave identically here. IMHO, not necessarily. For bash, I think we should keep the working solution. For zsh, a pragmatic approach with global options might be good enough.

Thanks for your input @albers, yes ideally, the options should match the actual situation, but I can live with doing it on a "best effort" base, and defining them globally

@thaJeztah The current version is without global_options, similar to what @albers has done with bash.
But I can modify it to make env labels and tag global if you want me to.

(I need to rebase before merge)

@sdurrheimer I'm good with the current approach (it's the "better" solution, albeit more demanding on maintenance), we can move to global options if it becomes to hard to maintain (just my 0.02c)

Ok rebased.

@vincentbernat for review.

Wouldn't it be easy to move the whole log-options state handling into the __docker_log_options function? $opt_args should be accessible directly from the function.

I've done a little refactoring.

LGTM

tag, env and labels added for splunk driver as requested in #17891

@thaJeztah

LGTM 🐮
We probably should wait for #17891 to be merged though, right ? 😝

Good to me

LGTM