-
Notifications
You must be signed in to change notification settings - Fork 5.3k
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
cp command: copy to all containers of a service as default behaviour #9437
Changes from 1 commit
601dae1
0647243
8b2eca4
046d6ca
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
@@ -55,7 +55,7 @@ func copyCommand(p *projectOptions, backend api.Service) *cobra.Command { | |||||||||
} | ||||||||||
return nil | ||||||||||
}), | ||||||||||
RunE: Adapt(func(ctx context.Context, args []string) error { | ||||||||||
RunE: AdaptCmd(func(ctx context.Context, cmd *cobra.Command, args []string) error { | ||||||||||
opts.source = args[0] | ||||||||||
opts.destination = args[1] | ||||||||||
return runCopy(ctx, backend, opts) | ||||||||||
|
@@ -64,8 +64,10 @@ func copyCommand(p *projectOptions, backend api.Service) *cobra.Command { | |||||||||
} | ||||||||||
|
||||||||||
flags := copyCmd.Flags() | ||||||||||
flags.IntVar(&opts.index, "index", 1, "Index of the container if there are multiple instances of a service [default: 1].") | ||||||||||
flags.IntVar(&opts.index, "index", 0, "Index of the container if there are multiple instances of a service [default: 1 when copying from a container].") | ||||||||||
flags.BoolVar(&opts.all, "all", false, "Copy to all the containers of the service.") | ||||||||||
flags.MarkHidden("all") //nolint:errcheck | ||||||||||
flags.MarkDeprecated("all", "By default all the containers of the service will get the source file/directory to be copied.") //nolint:errcheck | ||||||||||
Comment on lines
+69
to
+70
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Instead of the
Suggested change
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I prefer we have noose by end of line with a nolint comment vs start of line, where my mind will focus reading, for useless assignment |
||||||||||
flags.BoolVarP(&opts.followLink, "follow-link", "L", false, "Always follow symbol link in SRC_PATH") | ||||||||||
flags.BoolVarP(&opts.copyUIDGID, "archive", "a", false, "Archive mode (copy all uid/gid information)") | ||||||||||
|
||||||||||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a huge fan of specifying a default value that we change depending of the context of the
cp
command. if you have better idea to do it, let me knowThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps remove the
[default: 1 when copying from a container].
altogether? (note that Cobra already prints defaults, so in most cases, there's no need to manually put it in the description)As to the flag itself; are indexes guaranteed to start with
1
? (i.e., could a container be removed, and it starts with2
?)The "when copying from a container" is a bit confusing, as compose works with "services", correct? (in other words; I don't think there's an option to specify a container - for that you'd use
docker cp
ordocker container cp
.Overall I'm wondering a bit if we should have this option; my train of thought here is that;
docker cp
/docker container cp
for the "I know what I'm doing" situation.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we need to double check
index
is aligned witcompose exec --index
, and that we didn't duplicated the logic to select a target container here so that we enforce an homogeneous behaviorwhen copying from a container indeed only make sense with a single container as target. Either we should REQUIRE
index
to be set when multiple container match, or set "first indexed in the available ones" as default (which might not be1
) - but, again, should behave the same ascompose exec
While it obvious they can just run
docker exec <container>
as name is predicable with compose, for some reason (?)docker-compose exec
was introduced and adopted by many, probably because users prefer to rely on the same tool for everything (when you get a hammer...). So, even with containers as target, a compose command makes sense to them. Or maybe this helps writing scripts that do not depend on te project name (included in container name) set by project dir?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, so it was mostly around "when it's needed to target a specific instance"; I can see a good use for
docker compose exec
(where it automatically picks the (first) instance of the service). Mostly for--index
, because in that case, I would still need to do adocker compose ps
to learn about what indexes I can pick.Taking something like;
"just works":
Exec'ing into a specific instance, my natural approach would be to;
Get a list of what's running;
Then,
docker compose exec
into the one I want to access;But that doesn't work currently (so then I need to use
docker exec
), as it will treat it as service-name (also somewhat expected)So to do the same, I need to look at the output, pick the "index" / instance number, edit my command to pass it as
--index
;(wondering if we should make the
docker compose exec composescale-web-2
work 🤔)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why not, @ndeloof @ulyssessouza WDYT? I can do that in a follow up PR if we all agree
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(let me "unresolve" so that it's not hidden)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
docker compose exec <containername>
doesn't make sense to me, the whole verbage used by compose is service-centric. Use of--index
is unpleasant but I can't imagine a workaround. I'd just expect it's not required for service running 1 replica and user don't have to bother with this BUT when they try to diagnose a distributed-system issue with multiple replicas. But then, obviously, using plain container name withdocker exec
would be a natural option, and maybe we should deprecate--index
support and suggest user to better usedocker exec
for this purpose. Or maybe this is fine we keep this as legacy/usability, as we - at least - share runExec implementation code!