Skip to content
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

publish RunExec for use by docker/compose #3436

Merged
merged 1 commit into from
Feb 25, 2022

Conversation

ndeloof
Copy link
Contributor

@ndeloof ndeloof commented Feb 23, 2022

- What I did
make "exec" logic reusable by docker-compose without having to duplicate code

- How I did it
made runExec and execOptions public so this code can be reused in docker-compose

- How to verify it
see docker/compose#9197

- Description for the changelog

- A picture of a cute animal (not mandatory but encouraged)
image

Copy link
Member

@thaJeztah thaJeztah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Overall makes sense, but left some comments (I think newExecOptions() should probably be exported so that the correct ListOpts are set)

Also looks like a linter is complaining about missing Godoc

cli/command/container/exec.go:19:6: exported type `ExecOptions` should have comment or be unexported (golint)
type ExecOptions struct {
      ^

cli/command/container/exec.go:74:1: exported function `RunExec` should have comment or be unexported (golint)
func RunExec(dockerCli command.Cli, options ExecOptions) error {
   ^

type ExecOptions struct {
DetachKeys string
Interactive bool
Tty bool
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While we're changing this, could you change this to TTY? (it's an acronym)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess the one on types.ExecConfig is generated from swagger, so we can't do the same?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm... good question; actually, I don't think it is generated. Looking at https://github.com/moby/moby/blob/7b9275c0da707b030e62c96b679a976f31f929d3/api/types/configs.go#L30-L44

I don't see a "generated" comment in that file, so that one was probably done manually (but using the wrong casing 😞). The files that were generated have a comment somewhere at the top; https://github.com/moby/moby/blob/7b9275c0da707b030e62c96b679a976f31f929d3/api/types/plugin_env.go#L3-L4

// This file was generated by the swagger tool.
// Editing this file might prove futile when you re-run the swagger generate command

But it's a good point; perhaps (as a follow-up?) we should either use that type for the options here and/or create an alias for it in the api (or client) package.

Detach bool
User string
Privileged bool
Env opts.ListOpts
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not something to change, more "thinking out loud"; when we're gonna work on "slicing and dicing" bits to make them more reusable, we should have a good look at options like this (does it have to be a special opts.ListOpts type here, or could a generic type (such as a []string) work for these).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

docker/compose uses []string and some user reported the help make in unclear, as it says expected type is array.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, yes, the way Cobra generates the names for value types being directly related to the "type" used is often not very handy 😞

Was discussing that recently again with @crazy-max on docker/cli-docs-tool#19 (comment), where (it's kinda tacky, but we should improve things) we added an annotation to allow a custom "name" for values to be set (which could be somewhat more descriptive than stringArray (e.g.)

Workdir string
Container string
Command []string
EnvFile opts.ListOpts
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one needs some thinking as well (besides env-file being a PITA overall); EnvFile effectively is just an easy way to propagate Env; if we want to refactor things to make them more usable, we could decide to remove EnvFile option from this, and instead have an (easy to reuse) utility to append / update env-vars in Env from a file.

(no need to change, more "these are things we should look at")

cli/command/container/exec.go Show resolved Hide resolved
envFile: opts.NewListOpts(nil),
func newExecOptions() ExecOptions {
return ExecOptions{
Env: opts.NewListOpts(opts.ValidateEnv),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This shows a bit why I think we should look at whether or not opts.ListOpts as option is "handy", as the code using the ExecOptions would have to know that it needs to use a opts.ListOpts, but also that it needs to use one that has a specific validation rule set (opts.ValidateEnv).

Some utilities for this, adding some methods to ExecOptions itself, or perhaps using functional arguments could help for such cases.

(again, one more "these are things we should look at")

@thaJeztah thaJeztah added kind/refactor PR's that refactor, or clean-up code status/2-code-review labels Feb 24, 2022
@thaJeztah thaJeztah added this to the 21.xx milestone Feb 24, 2022
@codecov-commenter
Copy link

codecov-commenter commented Feb 24, 2022

Codecov Report

Merging #3436 (93e9b78) into master (cf8c4ba) will increase coverage by 0.95%.
The diff coverage is 56.14%.

@@            Coverage Diff             @@
##           master    #3436      +/-   ##
==========================================
+ Coverage   57.33%   58.28%   +0.95%     
==========================================
  Files         304      287      -17     
  Lines       26379    24144    -2235     
==========================================
- Hits        15124    14073    -1051     
+ Misses      10329     9212    -1117     
+ Partials      926      859      -67     

Copy link
Member

@thaJeztah thaJeztah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks for updating!

Remind me that we should write down some of the things we were discussing on this PR (I think this PR makes sense for the short term, but we really need to look at improving these things in the longer term, without having to export things that were not originally designed to be exported (so may not have been "very well designed" to be used externally).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/refactor PR's that refactor, or clean-up code status/2-code-review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants