✨ (go/v4): Added DevContainer support for seamless development in environments like GitHub Workspaces without local setup.

[TAM360]

Issue Link

3432

Description

This PR add the functionality of generating DevContainer configuration files along with rest of the Kubebuilder project during scaffolding.

Motivation

DevContainer is an Open Source tool which allows users consolidate their development environment into single container image. This image then can be shared across any environment by anyone. DevContainers can then be launched using any IDE including VSCode. Github's CodeSpaces uses the same tech underline.

In the context of Kubebuilder, having a DevContainer with Kind, Go, and Kubebuilder will allow any user to readily test their Operator's changes without installing any of the tools explicitly, thereby saving the time.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: TAM360 / name: Taimoor Mirza (79aa3d1)

[k8s-ci-robot]

Welcome @TAM360!

It looks like this is your first PR to kubernetes-sigs/kubebuilder 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/kubebuilder has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @TAM360. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[camilamacedo86]

/ok-to-test

[camilamacedo86]

/ok-to-test

[camilamacedo86]

HI @kannon92, @awfuel, @FabianKramm

I think you all were interest in this one and it seems great for me.
So, if you want spend some time in the review please feel free !

[caozhuozi]

I see vscode is hardcoded in the settings. If it is not a vendor agnostic feature, How about jetbrains IDE? they seems to be also support devcontainer

[TAM360]

I see vscode is hardcoded in the settings. If it is not a vendor agnostic feature, How about jetbrains IDE? they seems to be also support devcontainer

@caozhuozi It looks like the JetBrain's support for DevContainers is still in Beta phase. Maybe we can add them later, once it gets stable?

@camilamacedo86 any second thoughts?

[camilamacedo86]

Hi @caozhuozi, @TAM360

I see vscode is hardcoded in the settings. If it is not a vendor agnostic feature, How about jetbrains IDE? they seems to be also support devcontainer

I personally use JetBrains IDEs, but I recognize that a significant portion of users rely on VS Code since it's free and widely adopted. My preference would be to keep the setup vendor-agnostic for this reason. (each person has her/his own preferences and we never will make everybody happy). We also try to avoid dependencies with third-party as much as possible.

That said, it's straightforward for anyone to customize the setup according to their preference after the scaffold is created. So, I suggest we stick with VS Code as the default (given its common, free adoption) while allowing users the flexibility to modify their scaffold to suit their needs.

A second option would not have any IDE at all.
For we do not end up with requests of matter of preference as well.

[camilamacedo86]

/hold

We might need an small ajusts

[camilamacedo86]

Just for we have tracked at least here in a comment why it is required:
kubernetes-sigs/kind#2488 (comment)

[camilamacedo86]

/hold cancel

I think all missing nits are addressed now !!
Great work

[varshaprasad96]

Hi @TAM360, thanks for your contribution! This is amazing!

Looks good from my end! Just a small question - I personally don't use vscode anymore, but do we also need envtest binaries along with others to be able to test KB projects. We do have a makefile target that helps install this, but would it make it easier to have them in the container itself? (we can have this in follow up too if required)

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: camilamacedo86, TAM360, varshaprasad96

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [camilamacedo86,varshaprasad96]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment