Closed kannon92 closed 1 month ago
Hi @kannon92,
Could you please give an example of what you are looking for? Are you trying to create e2e tests where they would be executed in a devcontainer?
Yea, basically I want to develop and test my operator with a GitHub workspace/devcontainers. Ideally run unit/integration.
So I was going to see if I could figure out how to make my kubebuilder project run in a devcontainer but I was running into some issues because I’m not as familiar with this as I should.
But I was thinking that if there was any consideration on the roadmap for a template for generating a devcontainer for new kubebuilder projects.
Does that make sense?
Hi @kannon92,
It is an interesting request. To test the project you will need to:
make deploy IMG=<imagename>
You can check the e2e tests done in : https://github.com/operator-framework/operator-sdk/blob/master/testdata/go/v4-alpha/monitoring/memcached-operator/test/e2e/e2e_test.go#L114-L133 to know better those steps.
If you would like to push a PR with the solution in place I think that would be acceptable. In the worst scenario, If we see that would be much associated with an third-party we can either move with this code implementation for a plugin implementation where we could indeed scaffold other related helpers .
WDYT? Would you like to contribute with the project and propose a PR with this?
This I got from github docs as I was trying to understand the devcontainer or githubcode spaces. Acording to docs they are simple codespaces and different repository have different configuration where they add tools and things required for the the development of the specific project. Looks like we need to try to setup development configuration in codespaces of github. So it can be easy to develop things directly from github and no need of pulling the code to local.
I am interested in this pr but I would like to understand first to get to result.
Hi @kannon92,
It is an interesting request. To test the project you will need to:
- Have k8s installed (it can be kind for example)
- Then you will build the image, load the image, run make install and
make deploy IMG=<imagename>
You can check the e2e tests done in : https://github.com/operator-framework/operator-sdk/blob/master/testdata/go/v4-alpha/monitoring/memcached-operator/test/e2e/e2e_test.go#L114-L133 to know better those steps.
If you would like to push a PR with the solution in place I think that would be acceptable. In the worst scenario, If we see that would be much associated with an third-party we can either move with this code implementation for a plugin implementation where we could indeed scaffold other related helpers .
WDYT? Would you like to contribute with the project and propose a PR with this?
Hey @camilamacedo86,
Not sure if I have the bandwidth. I noticed that there was an initiative to make Kubernetes build in a devcontainer (https://github.com/kubernetes/kubernetes/issues/113019) and there seems to be a few issues in kind to set this up also.
Kind issue 1 (https://github.com/kubernetes-sigs/kind/issues/2967) and https://github.com/kubernetes-sigs/kind/issues/3196.
Hi @kannon92,
I remember that I did a test in the past using devcontainers to check the project running in the github workspace. I used this configuration, see: https://github.com/camilamacedo86/kubebuilder/blob/workspace/.devcontainer/devcontainer.json
See that used minikube instead. However, if you be able to use kind that is better because it is possible to build and load the image without need to push it to a registry. I am not sure if with minikube it is possible to do the same.
Can you please check this one and see if that works for you? If not, share the problems faced then we can try to help you out with.
Hello @kannon92 @camilamacedo86 I am just trying to help here. I have found a command through which we can build and load the image without pushing to registry in minikube.
eval $(minikube docker-env)
docker build -t my_image .
kubectl run my_image --image=my_image
eval $(minikube docker-env) : it is a bash command that will export a set of environment variables that point your Docker CLI to the Docker daemon inside the Minikube
Let me know if it helps.
Devcontainers are relatively very new and I went through the same (very frustrating) problem with kind that Kannon92 pointed out that it is so soon. That said there is an easier way to get started, you can use devpod https://devpod.sh/ to manage devcontainer workspaces and choose any backend provider you prefer (Docker and vscode integration to start is logical). One of many reasons to use devcontainer is so that it improves building isolation and removes any variations in developers local setup for building objects which should increase code quality long term. You can think of Devpod as similar to Podman or Toolbox (SIlverblue) or Codespaces but much more flexible as you can run and push your changes in git to source control anywhere. I intend to use it for an operator.
Hi @awfuel,
It is nice to know that this third-party can help out. However, I think here the goal would to be to share a config without the usage of ANY third-part at all. See that we just need a config with KIND to achieve the goal or minikube and load the image locally: https://minikube.sigs.k8s.io/docs/handbook/pushing/#7-loading-directly-to-in-cluster-container-runtime
@camilamacedo86 I created https://github.com/loft-sh/devpod-kubebuilder-template/blob/main/.devcontainer/devcontainer.json which is just a config that works for Github codespaces without any additional tools (solves the kind problem you mentioned).
DevPod is just an alternative tool (not an additional one) to Github codespaces (has the same config, also on the official website, see https://containers.dev/supporting#devpod), that allows you to run this configuration anywhere (including Kubernetes) and not just on Github hosted servers or the vscode devcontainer plugin.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
Use kind or minikube probably is no longer an issue within right. So, I think we could move forward with this one !
@camilamacedo86 I am gonna work on this issue.
/assign
Done on master
What do you want to happen?
Devcontainers/GitHub workspaces are becoming more popular ways of developing. Has there been any consideration on how to run a kube builder generates project as a devcontainer?
Extra Labels
/kind documentation