DockerCLI/cmd/docker/aliases.go

55 lines
1.4 KiB
Go
Raw Normal View History

package main
import (
"os"
"strings"
fix broken alias check is buildx is installed as alias for builder Commit cbec75e2f3f5afd3334db693829a6b150612076c updated `runDocker()` to load plugin-stubs before `processAliases()` was executed. As a result, plugin stubs were considered as "builtin commands", causing the alias verification to fail; Without alias installed: ```bash docker version Client: Version: 22.06.0-beta.0-140-g3dad26ca2.m API version: 1.42 Go version: go1.19.1 Git commit: 3dad26ca2 Built: Wed Sep 28 22:36:09 2022 OS/Arch: darwin/arm64 Context: default ... ``` After running `docker buildx install`; ```bash ./build/docker buildx install cat ~/.docker/config.json { "aliases": { "builder": "buildx" } } ./build/docker version not allowed to alias with builtin "buildx" as target ``` This patch moves loading the stubs _after_ the call to `processAliases()`, so that verification passes. As an extra precaution, the `processAliases()` function is also updated to exclude plugin-stub commands. Note that cbec75e2f3f5afd3334db693829a6b150612076c also introduced a performance regression, which may be related to the early loading of plugins (and creating stubs); it looks like various other code locations may also be loading plugins, for example `tryPluginRun()` calls `pluginmanager.PluginRunCommand()`, which also traverses plugin directories. We should look under what circumstances the plugin stub-commands are actually needed, and make sure that they're only created in those situations. Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-09-29 16:35:36 -04:00
pluginmanager "github.com/docker/cli/cli-plugins/manager"
"github.com/docker/cli/cli/command"
"github.com/pkg/errors"
"github.com/spf13/cobra"
)
const (
keyBuilderAlias = "builder"
)
var allowedAliases = map[string]struct{}{
keyBuilderAlias: {},
}
func processAliases(dockerCli command.Cli, cmd *cobra.Command, args, osArgs []string) ([]string, []string, []string, error) {
var err error
var envs []string
aliasMap := dockerCli.ConfigFile().Aliases
aliases := make([][2][]string, 0, len(aliasMap))
for k, v := range aliasMap {
if _, ok := allowedAliases[k]; !ok {
return args, osArgs, envs, errors.Errorf("not allowed to alias %q (allowed: %#v)", k, allowedAliases)
}
fix broken alias check is buildx is installed as alias for builder Commit cbec75e2f3f5afd3334db693829a6b150612076c updated `runDocker()` to load plugin-stubs before `processAliases()` was executed. As a result, plugin stubs were considered as "builtin commands", causing the alias verification to fail; Without alias installed: ```bash docker version Client: Version: 22.06.0-beta.0-140-g3dad26ca2.m API version: 1.42 Go version: go1.19.1 Git commit: 3dad26ca2 Built: Wed Sep 28 22:36:09 2022 OS/Arch: darwin/arm64 Context: default ... ``` After running `docker buildx install`; ```bash ./build/docker buildx install cat ~/.docker/config.json { "aliases": { "builder": "buildx" } } ./build/docker version not allowed to alias with builtin "buildx" as target ``` This patch moves loading the stubs _after_ the call to `processAliases()`, so that verification passes. As an extra precaution, the `processAliases()` function is also updated to exclude plugin-stub commands. Note that cbec75e2f3f5afd3334db693829a6b150612076c also introduced a performance regression, which may be related to the early loading of plugins (and creating stubs); it looks like various other code locations may also be loading plugins, for example `tryPluginRun()` calls `pluginmanager.PluginRunCommand()`, which also traverses plugin directories. We should look under what circumstances the plugin stub-commands are actually needed, and make sure that they're only created in those situations. Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-09-29 16:35:36 -04:00
if c, _, err := cmd.Find(strings.Split(v, " ")); err == nil {
if !pluginmanager.IsPluginCommand(c) {
return args, osArgs, envs, errors.Errorf("not allowed to alias with builtin %q as target", v)
fix broken alias check is buildx is installed as alias for builder Commit cbec75e2f3f5afd3334db693829a6b150612076c updated `runDocker()` to load plugin-stubs before `processAliases()` was executed. As a result, plugin stubs were considered as "builtin commands", causing the alias verification to fail; Without alias installed: ```bash docker version Client: Version: 22.06.0-beta.0-140-g3dad26ca2.m API version: 1.42 Go version: go1.19.1 Git commit: 3dad26ca2 Built: Wed Sep 28 22:36:09 2022 OS/Arch: darwin/arm64 Context: default ... ``` After running `docker buildx install`; ```bash ./build/docker buildx install cat ~/.docker/config.json { "aliases": { "builder": "buildx" } } ./build/docker version not allowed to alias with builtin "buildx" as target ``` This patch moves loading the stubs _after_ the call to `processAliases()`, so that verification passes. As an extra precaution, the `processAliases()` function is also updated to exclude plugin-stub commands. Note that cbec75e2f3f5afd3334db693829a6b150612076c also introduced a performance regression, which may be related to the early loading of plugins (and creating stubs); it looks like various other code locations may also be loading plugins, for example `tryPluginRun()` calls `pluginmanager.PluginRunCommand()`, which also traverses plugin directories. We should look under what circumstances the plugin stub-commands are actually needed, and make sure that they're only created in those situations. Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-09-29 16:35:36 -04:00
}
}
aliases = append(aliases, [2][]string{{k}, {v}})
}
args, osArgs, envs, err = processBuilder(dockerCli, cmd, args, os.Args)
if err != nil {
return args, os.Args, envs, err
}
for _, al := range aliases {
var didChange bool
args, didChange = command.StringSliceReplaceAt(args, al[0], al[1], 0)
if didChange {
osArgs, _ = command.StringSliceReplaceAt(osArgs, al[0], al[1], -1)
break
}
}
return args, osArgs, envs, nil
}