@craiglpeters: The label(s) sig/contribex cannot be applied, because the repository doesn't have them.

/sig contributor-experience

/cc @Debanitrkl @Harshitavkb26 @Rishit-dagli

We had a discussion on permission based issues regarding enabling code spaces for k/k, I think it would be better to run it through SIG-Infra once to see how can we set it up for k/k, because at the moment building kubernetes on code spaces base tier isn't possible yet.

We had a discussion on permission based issues regarding enabling code spaces for k/k, I think it would be better to run it through SIG-Infra once to see how can we set it up for k/k, because at the moment building kubernetes on code spaces base tier isn't possible yet.

@Debanitrkl can you help me understand what you mean? I am currently testing building kubernetes in a default codespace and haven't faced any issues yet.

We had a discussion on permission based issues regarding enabling code spaces for k/k, I think it would be better to run it through SIG-Infra once to see how can we set it up for k/k, because at the moment building kubernetes on code spaces base tier isn't possible yet.

AFAIK we don't need to do any permissions change to create a default code space. We don't have to configure it so spinning things up would come out of the orgs allocation.

We had a discussion on permission based issues regarding enabling code spaces for k/k, I think it would be better to run it through SIG-Infra once to see how can we set it up for k/k, because at the moment building kubernetes on code spaces base tier isn't possible yet.

@Debanitrkl can you help me understand what you mean? I am currently testing building kubernetes in a default codespace and haven't faced any issues yet.

I was trying out the the make verify and make all and I get the following message:
High codespace CPU (98.5%) utilization detected. Consider stopping some processes for the best experience.

The Codespaces configuration consists of a Development Container (devcontainer) file devcontainer.json which encodes the configuration of the environment.

Also, since it directly spins-up a development environment, we need to have the pre-requisite environment configuration defined in devcontainer.json, but since that may vary for different use cases are we planning to have all the pre-requisites to be set-up by default in the environment.

We had a discussion on permission based issues regarding enabling code spaces for k/k, I think it would be better to run it through SIG-Infra once to see how can we set it up for k/k, because at the moment building kubernetes on code spaces base tier isn't possible yet.

@Debanitrkl can you help me understand what you mean? I am currently testing building kubernetes in a default codespace and haven't faced any issues yet.

I was trying out the the make verify and make all and I get the following message: High codespace CPU (98.5%) utilization detected. Consider stopping some processes for the best experience.

Presently these all tests fail for less disk space on running make verify

FAILED   verify-publishing-bot.py       1s
========================
FAILED TESTS
========================
hack/make-rules/../../hack/verify-conformance-requirements.sh
hack/make-rules/../../hack/verify-golangci-lint.sh
hack/make-rules/../../hack/verify-govet.sh
hack/make-rules/../../hack/verify-import-aliases.sh
hack/make-rules/../../hack/verify-import-boss.sh
hack/make-rules/../../hack/verify-imports.sh
hack/make-rules/../../hack/verify-internal-modules.sh
hack/make-rules/../../hack/verify-mocks.sh
hack/make-rules/../../hack/verify-openapi-spec.sh
hack/make-rules/../../hack/verify-spelling.sh
hack/make-rules/../../hack/verify-typecheck.sh
hack/make-rules/../../hack/verify-vendor-licenses.sh
hack/make-rules/../../hack/verify-vendor.sh
hack/make-rules/../../hack/verify-yamlfmt.sh
hack/make-rules/../../hack/verify-publishing-bot.py
make: *** [Makefile:128: verify] Error 1

@Debanitrkl it seems that you are using a machine with too few resources. It may be the case that you don't (yet) have access to larger machines. Soon everyone will have access to larger machines, but I can help you get access to a larger machine to test on now.

Update: I tested with a 4 core codespace and could make verify without issue, and provided @Debanitrkl with access to the same to verify.

I would also hope for gitpod

We'd accept a gitpod config, but would need someone to take ownership of maintaining it.

/triage accepted

cc: @pymander

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

/remove-lifecycle stale
/lifecycle frozen

This seems to have moved beyond just a config file in the repo: kubernetes/test-infra#30454 (comment), kubernetes/org#4468

@BenTheElder Just to be clear - I think support for devcontainers can come in many forms, based on speed to launch, complexity and reliability. Depending on how Kubernetes would like "per-repo" tools to work, the implementation can change.

/assign

https://kubernetes.slack.com/archives/C1TU9EB9S/p1714223550391479?thread_ts=1713701062.612009&cid=C1TU9EB9S