Add option to disable pushing images manually #4587
Labels
enhancement
New feature or request
Comments
nicks
added a commit
that referenced
this issue
May 27, 2021
…diately" We used to treat this as a property of the cluster type + the container runtime. But this made it impossible to support things clusters that sometimes use your docker runtime, and sometimes do not. For examples, see: - #4587 - #3654 - #1729 - #4544 This changes the data model so that "image builds show up in the cluster" is a property of the Docker client, not of the cluster. This should be much more flexible and correct, and help us support multiple clusters. Fixes #4544
nicks
added a commit
that referenced
this issue
May 27, 2021
…diately" We used to treat this as a property of the cluster type + the container runtime. But this made it impossible to support clusters that sometimes use your docker runtime, and sometimes do not. For examples, see: - #4587 - #3654 - #1729 - #4544 This changes the data model so that "image builds show up in the cluster" is a property of the Docker client, not of the cluster. This should be much more flexible and correct, and help us support multiple clusters. Fixes #4544
|
thanks for the report! I'm going to mark this as a duplicate of #3654, since i think they're basically the same issue |
nicks
added a commit
that referenced
this issue
Jun 7, 2021
…diately" (#4598) * docker: change how we model "image builds show up in the cluster immediately" We used to treat this as a property of the cluster type + the container runtime. But this made it impossible to support clusters that sometimes use your docker runtime, and sometimes do not. For examples, see: - #4587 - #3654 - #1729 - #4544 This changes the data model so that "image builds show up in the cluster" is a property of the Docker client, not of the cluster. This should be much more flexible and correct, and help us support multiple clusters. Fixes #4544 * Update internal/docker/env.go Co-authored-by: Maia McCormick <maia@windmill.engineering> Co-authored-by: Maia McCormick <maia@windmill.engineering>
landism
pushed a commit
that referenced
this issue
Jun 9, 2021
…diately" (#4598) * docker: change how we model "image builds show up in the cluster immediately" We used to treat this as a property of the cluster type + the container runtime. But this made it impossible to support clusters that sometimes use your docker runtime, and sometimes do not. For examples, see: - #4587 - #3654 - #1729 - #4544 This changes the data model so that "image builds show up in the cluster" is a property of the Docker client, not of the cluster. This should be much more flexible and correct, and help us support multiple clusters. Fixes #4544 * Update internal/docker/env.go Co-authored-by: Maia McCormick <maia@windmill.engineering> Co-authored-by: Maia McCormick <maia@windmill.engineering>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the Feature You Want
Right now tilt disables push only if k8s is minikube ( and few others). I've made a setup with
k3s --dockerwhich basically makes k3s to use the already installed docker daemon. This leads to a push which is not needed at all because after the build I always the get messageContainer image "..." already present on machine. This is normal as both k3s and tilt use the same docker daemon.Current Behavior
Needless push if using tilt with
k3s --dockeras dev cluster.Why Do You Want This?
I would like to skip waiting for a push which is not needed anyway.
The text was updated successfully, but these errors were encountered: