-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Unify local development experience between Makefile and DevContainers #4411
Comments
Hi @migueleliasweb, Thank you for raising the suggestion! To have the DevContainers running, we currently do the following:
What targets would you like to add to the Makefile? Adding a target to install the Kubebuilder CLI in the scaffold of projects generated by the Kubebuilder CLI itself wouldn’t make much sense, right? Are you suggesting a target to install the latest version of Kind or something else?
Inside of the DevContainer if you run make tests, will not the envtest binaries be installed? Why do you are looking for to pre-install those? It would be great if you could clarify your suggestion with an example. Looking forward to your thoughts! |
Thank you a lot for your wish to make the project better. After reviewing the discussion in the Slack thread here, and based on the clarifications provided, I’d like to address the request and explain why this RFE cannot be accommodated. It seems the proposal aims to pre-install what is currently achieved via the Makefiles. However, this approach introduces significant challenges:
You are, of course, free to modify and tailor your project to meet specific needs. However, for Kubebuilder scaffolds, adhering to these common practices ensures a stable, predictable foundation for the majority of users. All that is commonly adopted by the community and is considered a common practice. Makefile fails under this category. For these reasons, I will be closing this issue. Thank you for your suggestion, and I hope the explanation clarifies our stance. If, for any reason, I misunderstood it, please feel free to re-open it. |
Hi @camilamacedo86, thanks for the swift reply! My intent has to provide a way to, for both locally or through DevContainers, setup a development environment with all the tooling needed for Kubebuilder. Myself, and I'm sure many others don't really use the Makefile to run tests (and install the tools themselves) and instead opt to write their own entrypoint script for this (via My rationale is that, especially when running with DevContainers, the environment should be ready to go with the necessary tools, such as:
Currently, these are configured via Makefile (most of them) but when using the DevContainers, the experience could be improved as DevContainers are ephemeral by nature and runtime changes will be lost if the container is rebuilt. Meaning, if I manually run a Makefile target such as I should have given a more concrete proposal on my first message so I'll try to make it clearer this time. Proposal
Note that we're already setting up With these changes, the DevContainers environment will be consistent with the local environment even after a rebuild. It'll also require users of Kubebuilder to modify less of the project, which can greatly help with maintaining compatibility with future releases of the CLI itself. I hope this clarifies my proposal as I didn't meant to replace Makefile as I'm aware Kubebuilder is invested in that space and also the overall benefits would not the that big. |
Hi @migueleliasweb, Thank you for your detailed explanation of your comment. Currently, the following tools are already installed in the DevContainers:
Additionally, we have:
Based on this, it doesn’t seem necessary to create a script to install all tools preemptively. The Makefile already ensures that required tools are installed only when needed, and only if the corresponding actions are executed. For users not utilizing the Makefile, it is their responsibility to handle dependencies. By design, all actions are centralized in the Makefile, which aligns with common practices across stacks. There isn’t much appetite to change this approach, as it is widely adopted and effective. Adding a pre-installation step for tools that may not even be used would unnecessarily increase the container’s runtime and size. Many users may prefer a lighter, faster DevContainer that can accommodate additional tools only when required. Also, indeed, we might change how things work by adopting the new feature provided by Go: #4412. Therefore, I would say let's work in the #4412, let's check if we should or should not change things, and then it might change the experience for our DevContainers. I hope that makes sense. |
What do you want to happen?
Currently, the experience is split between using Makefile to setup the local binaries and paths needed for local testing and using DevContainers.
Both approaches are great and work but there is no direct reference between the setup of the two.
E.g: If one has setup the Makefile to use specific versions of the
env-test
or other binaries, these versions are not picked up when using the DevContainer as thepost-install
script does no use Makefile to set everything up.Proposal:
post-install
script to then the experience is similar between the twoIdeally the setup shold be identical, meaning, either the Makefile is only used to run bash-like scripts that then are shared to the DevContainers setup or the DevContainers
json
file only calls to Makefile targets to setup the environment.I'm happy to create a POC if everyone things there is value on bringing those two local dev environments closer together.
Thanks!
Extra Labels
No response
The text was updated successfully, but these errors were encountered: