-
Notifications
You must be signed in to change notification settings - Fork 506
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
builder: skip name validation for docker context #1879
Conversation
Although a builder from the store cannot be created unless it has a valid name, this is not the case for a Docker context. We should skip name validation when checking a node from the store and fall back to finding one from Docker context instead. Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
5585460
to
b1c5449
Compare
Interesting; it looks like context-store in docker/cli does have a validation function; buildx/vendor/github.com/docker/cli/cli/context/store/store.go Lines 214 to 226 in bd672ea
buildx/vendor/github.com/docker/cli/cli/context/store/store.go Lines 22 to 24 in bd672ea
But I was actually looking at other parts of the code, and it looks like validation is done externally 😞 https://github.com/docker/cli/blob/085d5c281612298583d19806aa8ec637b572e4cc/cli/command/context/create.go#L124-L135 func checkContextNameForCreation(s store.Reader, name string) error {
if err := store.ValidateContextName(name); err != nil {
return err
}
if _, err := s.GetMetadata(name); !errdefs.IsNotFound(err) {
if err != nil {
return errors.Wrap(err, "error while getting existing contexts")
}
return errors.Errorf("context %q already exists", name)
}
return nil
} // RunCreate creates a Docker context
func RunCreate(cli command.Cli, o *CreateOptions) error {
s := cli.ContextStore()
err := checkContextNameForCreation(s, o.Name)
if err != nil {
return err
}
swit So I wonder if there's a bug at hand here, where validation was missed? |
Oh good catch @thaJeztah. Yeah there's smth fishy here 🤔 |
Yeah, was looking "why isn't the validation done by the context store code?", and then saw this PR fly by in my notifications 😂 Is the case here that BuildKit / buildx can use either hostname or context-name, and doesn't know which is the case? |
This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [docker/buildx-bin](https://github.com/docker/buildx) | stage | patch | `0.11.0` -> `0.11.2` | --- ### Release Notes <details> <summary>docker/buildx (docker/buildx-bin)</summary> ### [`v0.11.2`](https://github.com/docker/buildx/releases/tag/v0.11.2) [Compare Source](docker/buildx@v0.11.1...v0.11.2) Welcome to the v0.11.2 release of buildx! Please try out the release binaries and report any issues at https://github.com/docker/buildx/issues. ##### Contributors - [Justin Chadwell](https://github.com/jedevc) - [CrazyMax](https://github.com/crazy-max) - [Sebastiaan van Stijn](https://github.com/thaJeztah) ##### Changes - Fix a regression that caused buildx to not read the `KUBECONFIG` path from the instance store [#​1941](docker/buildx#1941) - Fix a regression with result handle builds showing up in the build history incorrectly [#​1954](docker/buildx#1954) ##### Dependency Changes - **github.com/docker/docker** v24.0.2 -> [`36e9e79`](docker/buildx@36e9e796c6fc) - **github.com/moby/buildkit** [`67a0862`](docker/buildx@67a08623b95a) -> [`faa0cc7`](docker/buildx@faa0cc7da353) - **github.com/tonistiigi/fsutil** [`9e7a6df`](docker/buildx@9e7a6df48576) -> [`36ef4d8`](docker/buildx@36ef4d8c0dbb) - **github.com/xeipuuv/gojsonpointer** [`4e3ac27`](docker/buildx@4e3ac2762d5f) -> [`02993c4`](docker/buildx@02993c407bfb) Previous release can be found at [v0.11.1](https://github.com/docker/buildx/releases/tag/v0.11.1) ### [`v0.11.1`](https://github.com/docker/buildx/releases/tag/v0.11.1) [Compare Source](docker/buildx@v0.11.0...v0.11.1) Welcome to the v0.11.1 release of buildx! Please try out the release binaries and report any issues at https://github.com/docker/buildx/issues. ##### Contributors - [CrazyMax](https://github.com/crazy-max) - [Justin Chadwell](https://github.com/jedevc) - [David Karlsson](https://github.com/dvdksn) - [Jhan S. Álvarez](https://github.com/yastanotheruser) ##### Changes - Fix a regression for bake where services in profiles would not be loaded. [#​1903](docker/buildx#1903) - Fix a regression where `--cgroup-parent` option had no effect during build. [#​1913](docker/buildx#1913) - Fix a regression where valid docker contexts could fail buildx builder name validation. [#​1879](docker/buildx#1879) - Fix an issue where the `host-gateway` special address could not be used as an argument to `--add-host`. [#​1894](docker/buildx#1894) (also requires moby/moby#45767) - Fix a possible panic when terminal is resized during the build. [#​1929](docker/buildx#1929) ##### Dependency Changes - **github.com/docker/cli-docs-tool** v0.5.1 -> v0.6.0 Previous release can be found at [v0.11.0](https://github.com/docker/buildx/releases/tag/v0.11.0) </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Enabled. ��� **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy4yMy4wIiwidXBkYXRlZEluVmVyIjoiMzcuMjQuMCIsInRhcmdldEJyYW5jaCI6Im1haW4ifQ==--> Reviewed-on: https://codeberg.org/woodpecker-plugins/docker-buildx/pulls/85 Co-authored-by: Patrick Schratz <pat-s@mailbox.org> Co-committed-by: Patrick Schratz <pat-s@mailbox.org>
related to docker/for-win#13543
Although a builder from the store cannot be created unless it has a valid name, this is not the case for a Docker context.
We should skip name validation when checking a node from the store and fall back to finding one from Docker context instead.