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

Introduce a Go workspace #18409

Open
ivanvc opened this issue Aug 6, 2024 · 3 comments
Open

Introduce a Go workspace #18409

ivanvc opened this issue Aug 6, 2024 · 3 comments
Labels
area/tooling backport/v3.5 priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. type/feature

Comments

@ivanvc
Copy link
Member

ivanvc commented Aug 6, 2024

What would you like to be added?

After discussing this in last week's community meeting and based on feedback from the Go team (golang/go#68254) due to the vulnerability (GHSA-5x4g-q5rc-36jp / golang/vulndb#2952), there are several benefits to introducing a Go workspace in the project, and one of the biggest motivations is to simplify the test scripts.

I have a branch with the go.workspace (diff). It requires changes in the build scripts and the test libraries. It still doesn't work, but there's some progress.

I mostly based it on how kubernetes/kubernetes defines the Go workspace. However, from golang/go#68254 and the motivation to have govulncheck spot vulnerabilities within our modules, their suggestion is to remove replaces pointing to local code in go.mods, but k/k still has these replaces.

I wanted to open up the discussion to get feedback and/or implementation ideas.

Why is this needed?

To improve the code quality and to spot vulnerabilities in our code firsthand.

@ahrtr
Copy link
Member

ahrtr commented Aug 7, 2024

High level I support this. I raised this about 3 years ago #13478, but go workspace wasn't widely used at that time. It should good timing now.

@jmhbnz jmhbnz added the priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. label Aug 11, 2024
@ivanvc
Copy link
Member Author

ivanvc commented Aug 22, 2024

This was discussed during the community meeting. I'll draft a document to discuss options for implementing this change.

@ivanvc
Copy link
Member Author

ivanvc commented Sep 18, 2024

I'm sorry it took me a very long time to draft the previously mentioned document. Here's the draft: https://docs.google.com/document/d/1Vpb0SosYT05YsBsgfJFzOAbSgitd1BcFOQzjEARaQyM. @ahrtr, PTAL and let me know your thoughts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/tooling backport/v3.5 priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. type/feature
Development

No branches or pull requests

3 participants