[WIP] Added Cloudbuild.yaml & README.md

[Sharpz7]

Closes #devcontainer

/cc @dims @craig

Please do not approve for CI

Doing an initial search of the docs I cannot find anything to guide me. I saw initially that most cloudbuild.yamls were in the images/builder folder, but some were not and I am not sure if that is where this image belongs.

Thanks in advance.

[k8s-ci-robot]

Welcome @Sharpz7!

It looks like this is your first PR to kubernetes/test-infra 🎉. 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/test-infra 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 @Sharpz7. Thanks for your PR.

I'm waiting for a kubernetes 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/test-infra repository.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Sharpz7
Once this PR has been reviewed and has the lgtm label, please assign stevekuznetsov for approval. For more information see the Kubernetes Code Review Process.

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

Needs approval from an approver in each of these files:

• OWNERS

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

[rjsadow]

What container image does this build?

[Sharpz7]

So devcontainers are build from devcontainer.jsons, so in this case it is https://github.com/craiglpeters/kubernetes-devcontainer/blob/master/.github/.devcontainer/devcontainer.json. There is no Dockerfile involved. It doesn't have to be that way, but I imagine the standard would prefer it go that way? @craiglpeters

[rjsadow]

I see, is there a reason we're pulling that devcontainer.json from @craiglpeters repo instead of adding it in completely? Or, maybe @craiglpeters , is there an effort to setup a community repo that includes that file along with any others that would be needed? I feel hesitant to add in dependencies from individual/non-community repositories.

[Sharpz7]

Yeah, so that is 100% the end-goal - it will be in the main repo. I think we were looking into the CI process first. This is more of an experiment than anything.

The problem is the devcontainer stuff will not work until this image exists, so it creates on interesting issue. We would end up looking like we support dev-containers, but we won't until this is up. Honestly, writing this down makes me think we should re-design how its setup? Potentially put the building devcontainer.json in this repo?

@craiglpeters what do you think?

[rjsadow]

Is there a larger idea for using dev containers widely throughout the k8s projects? This might be a good topic to bring up to sig-architecture to see if they have recommendations on whether each project should have its own config or there should be a separate repo with all devcontainer.json's.

[Sharpz7]

I am relatively new to the organisation side of this, is there a set-way to start a discussion around this? Or would it be a case of asking them on slack in their respective channels?

[rjsadow]

Slack is always a great place to start and ask general question. A more formal way of raising a point of discussion to a SIG would be to add it to a meeting agenda and having a discussion with them during their weekly (or biweekly) meetings. For example, SIG-ContribEx has meetings every other week on Wednesdays and you can view the agenda/notes here. Each sig organizes their meetings a little differently so if you have any question about how to add a meeting topic or if this is the right forum to discuss your topic, reach out to them in slack. You can see a full list of all of the sigs here but like I said before, I think SIG-ContribEx and/or SIG-Arch would be a great place to start for this type of change.

[Sharpz7]

Great! I am going to wait to see if I hear back from Craig. If not, I will look into this next week :))

[rjsadow]

Awesome, best of luck! And if you need anything from me feel free to reach out on here or slack.

[craiglpeters]

Hi - thanks for looking into this! This idea has been discussed extensively with #sig-contribex for Kubernetes. The intent is to add the link to starting your contribution experience to Kubernetes to the new contributor onboarding course. The effort to create the config has been a little stop and start, but now has some good momentum. See these Slack threads (Me asking for help, Me asking for help validating, Adam re Coder).

Creating this container image will enable people to have a complete and reproducible development environment that can be run locally using the devcontainer cli or the VS Code Remote Container, or run in various cloud services that support dev containers like Coder, DevPod, and GitHub Codespaces (the product I work on). A prebuilt image will work great when users create their own forks of the k/k repo.

One important consideration is to have a configuration for each branch of k/k that has a dependency on a different version of Go.

Regarding other projects (some already have devcontainer.json files - see containerd & etcd for example), once we have this pattern, I definitely would love to see prebuilt images so that projects can take advantage of them. Whether the configurations are managed in a single centralized repo, or distributed to each of the orgs that want to take advantage is not something I'm at all opinionated about. Seems to me that someone from the infrastructure team would be much more qualified to comment.