Skip to content
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

Closed
migueleliasweb opened this issue Dec 5, 2024 · 4 comments
Closed
Labels
kind/feature Categorizes issue or PR as related to a new feature. triage/needs-information Indicates an issue needs more information in order to work on it.

Comments

@migueleliasweb
Copy link

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 the post-install script does no use Makefile to set everything up.

Proposal:

  • Changes to Makefile to add a target that installs all needed binaries without the need to run tests
  • Use this Makefile target inside the post-install script to then the experience is similar between the two

Ideally 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

@migueleliasweb migueleliasweb added the kind/feature Categorizes issue or PR as related to a new feature. label Dec 5, 2024
@camilamacedo86
Copy link
Member

camilamacedo86 commented Dec 6, 2024

Hi @migueleliasweb,

Thank you for raising the suggestion!

To have the DevContainers running, we currently do the following:
post-install.sh script, which installs:

  1. Kind
  2. Kubebuilder CLI

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?

If one has setup the Makefile to use specific versions of the env-test or other binaries

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!

@camilamacedo86 camilamacedo86 added the triage/needs-information Indicates an issue needs more information in order to work on it. label Dec 6, 2024
@camilamacedo86
Copy link
Member

Hi @migueleliasweb

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:

  • Testing and Maintenance: By bypassing the Makefile, we’d be introducing code paths that cannot be effectively tested or guaranteed to work reliably across various environments.
  • Performance Impact: Pre-installing or modifying workflows outside of the Makefile would increase the time required to run containers unnecessarily, adding overhead without clear benefits.
  • Project Design Philosophy: The entire project architecture is designed around the Makefile to run all targets consistently and reliably. It serves as the central point for managing build, test, and deployment tasks. Moving away from this would diverge from the core principles and introduce unnecessary complexity.
  • Established Best Practices: Kubebuilder scaffolds follow established best practices and aim to provide consistency across projects. While I understand the motivation to avoid Makefiles entirely, this is not feasible for the broader community using these scaffolds. Any deviation would lead to fragmentation and inconsistency, undermining the goal of shared standards.

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.

@migueleliasweb
Copy link
Author

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 launch.json, tasks.json if you're using VSCode or even manually). This is simply because of the ease of development when you have it better integrated with your IDE.

My rationale is that, especially when running with DevContainers, the environment should be ready to go with the necessary tools, such as:

  • Kubebuilder CLI
  • EnvTest
  • Kustomize
  • Controller Gen
  • Kubectl
  • Optionally: GolangCI, kind

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 make envtest, next time I rebuild my container, that binary won't be present and I'll have to run the command again.

I should have given a more concrete proposal on my first message so I'll try to make it clearer this time.

Proposal

  • Create a Makefile target that installs tools: make install-tools
    • This target will install all required tools and also optionally install tools such as GolangCI and Kind (via an enable flag)
    • The target can be a "bare target" that has the necessary targets as dependencies so very little change is needed here
    • No changes are required in existing Makefile targets
  • Re-use this target on the post-install.sh to provide a consistent experience for local development inside Containers

Note that we're already setting up kind and kubectl via the post-install.sh script, which are optional whe running tests, so adding the other required tools (which would be installed anyway if you run make test) makes sense.


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.

@camilamacedo86
Copy link
Member

camilamacedo86 commented Dec 9, 2024

Hi @migueleliasweb,

Thank you for your detailed explanation of your comment.

Currently, the following tools are already installed in the DevContainers:

  • Kubebuilder CLI
  • Kubectl
  • Kind

Additionally, we have:

  • EnvTest: Installed only if you run the tests. If you execute make test, it will be installed locally AND in the DevContainer.
  • Kustomize: Required only if you run make manifests or make generate. If you execute these targets, the controller-gen binary will also be installed automatically, either locally AND/OR in the DevContainer.
  • Controller-Gen: Same as above.
  • GolangCI: Required only if you run make lint or make lint-fix. Again, it will be installed automatically as needed.

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.
Thank you a lot for raising it anyway

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. triage/needs-information Indicates an issue needs more information in order to work on it.
Projects
None yet
Development

No branches or pull requests

2 participants