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

✨ Improve developer tooling #382

Open
wants to merge 26 commits into
base: main
Choose a base branch
from

Conversation

tomasaschan
Copy link
Contributor

@tomasaschan tomasaschan commented Mar 12, 2025

The purpose of this PR is to make a bunch of improvements to the developer tooling, over what was scaffolded by Kubebuilder and hacked together on top of that. For more discussion, see #372.

Guiding principles

These are a couple of principles I'm trying to use for guidance on how to set things up:

Expose tools through go tool

By adding tools as dependencies in go.mod, through go get -tool ..., we make it so that as little as possible, other than a modern Go toolchain, is required to start contributing to the project. In addition,
this makes it easier for automation to manage version bumps etc.

Make as much as possible go through the go toolchain

We should be able to run tests with go test ./..., generate code and other artifacts using go generate ./..., and so on. The dependency on a Makefile to document how to run third-party tools is a smell.

Sometimes it cannot be avoided; e.g. there is currently no way to hook into go vet that would allow us to configure e.g. golangci-lint and govulncheck to run through that, but where possible we should try to avoid using other CLI entrypoints than go itself.

One True Way

There should only be one way to do something; for example, today we have the config directory which exposes a way to assemble all the config required to deploy kro by means of kustomize build, but we also have a Helm chart that results in similar but not identical config. We should unify those (and find other cases of "more than one way to do stuff") so that if you figured out how you can do something, you also figured out how you should do it.

Progress and ideas

  • Automate generating license headers with go generate
  • Automate running attribution-gen with go generate
  • Automate running controller-gen with go generate
  • Make controller-gen emit only the stuff we care about (CRDs, perhaps manager config, but not RBAC) and emit it into the Helm chart directly
  • Register any other developer tools in go.mod and get rid of hack/toolchain.sh
  • Get rid of the dependency on setup-envtest to run tests, by means of hooking into ✨ envtest: add option to download binaries, bump envtest to v1.32.0 kubernetes-sigs/controller-runtime#3135
  • Get rid of Make targets for building images and instead document how to do it with go tool ko; also set up Github Actions to do it in CI
  • Get rid of Make targets for deploying to local test clusters, and instead just document how to set up a test environment
  • Get rid of Make targets for packaging and publishing the Helm chart, and instead do that in Github Actions
  • Get rid of the /config directory in favor of /helm as the source of truth for how to install kro

We'll see how much of this I do in this PR and how much will be punted for later. The diff is already quite large, but basically anything that's not in the tool section of go.mod, or in the new files codegen.go and .nwa-config.yaml, is generated.

@tomasaschan tomasaschan force-pushed the devtools branch 5 times, most recently from 13333f8 to 3f3ae20 Compare March 13, 2025 13:19
@tomasaschan
Copy link
Contributor Author

@a-hilaly The tests are now failing because the bump of sigs.k8s.io/controller-runtime from ae0b66d also brings in github.com/google/[email protected] which seems to have a breaking change compared to what the tests assume. Not sure I understand enough of what's going on in those tests to fix them 😞 Do you have any input?

@tomasaschan
Copy link
Contributor Author

@a-hilaly I figured out the test failures; #388 should fix it. I'll incorporate that change here to unblock this work.

@tomasaschan tomasaschan marked this pull request as ready for review March 14, 2025 15:11
@tomasaschan
Copy link
Contributor Author

I think this is ready for a proper review now!

The change set is huge, because the automated changes touch almost every file. Most of it is whitespace changes in the license headers (🤦🏻) but I've tried to separate out the generated changes into separate commits to make them easier to ignore when reviewing.

There were also a few tools being mentioned and installed that weren't actually used anywhere - e.g. cosign and govulncheck; I'm assuming here that those were installed aspirationally, and I'm punting adding those into the project for a future time when we actually want to integrate them in the other workflows.

Most of the local development workflow should now be covered by go <cmd> - e.g. go vet ./..., go test ./..., go generate ./... and go run ./...; most of what is not possible to with native commands, but which you might want to do locally anyway, is encapsulated in go tool, e.g. go tool golangci-lint run or go tool ko build ....

Some things, e.g. releasing new versions, is no longer "easy" to do locally, because I feel they shouldn't be done locally - they should be done from GH actions, in response to merges or tags being pushed. That's why basically all helm stuff is just removed.

(I realize as the build turns red that I might have to iterate a couple of times on the GH actions here... please bear with me!)

@tomasaschan tomasaschan force-pushed the devtools branch 2 times, most recently from 9643011 to 79e3f03 Compare March 14, 2025 22:03
@tomasaschan
Copy link
Contributor Author

(There; rebased to get rid of conflicts in go.{mod,sum} after merging #388)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

are these deleted because they are no longer generated?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct; we now put all generated manifests (and some hand-crafted) in the helm chart directly, so there is no longer any kustomization going on.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Note that there is a corresponding CRD file generated in helm/templates/crds; the rest of the stuff in here is basically unused in the default scaffolding from kubebuilder.)

k8s.io/apiextensions-apiserver v0.33.0-beta.0
k8s.io/apimachinery v0.33.0-beta.0
k8s.io/apiserver v0.33.0-beta.0
k8s.io/client-go v0.33.0-beta.0
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

might not want to upgrade to a pre release of client go yet.

k8s.io/apiserver v0.33.0-beta.0
k8s.io/client-go v0.33.0-beta.0
k8s.io/kube-openapi v0.0.0-20250304201544-e5f78fe3ede9
sigs.k8s.io/controller-runtime v0.20.1-0.20250313041745-d82dcd80ca96
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Likely want to roll this back to a stable release

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both client-go and controller-runtime are bumped to pre-release to get access to kubernetes-sigs/controller-runtime#3135 (and the follow-up fix 3137); they should be released in v0.20.4 shortly, and then we should use that.

@@ -66,15 +68,16 @@ func New(controllerConfig ControllerConfig) (*Environment, error) {
env.TestEnv = &envtest.Environment{
CRDDirectoryPaths: []string{
// resourcegraphdefinition CRD
filepath.Join("../../../..", "config", "crd", "bases"),
filepath.Join("..", "..", "..", "..", "helm", "templates", "crds"),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is a good catch, the old way would make windows sad

@a-hilaly
Copy link
Member

a-hilaly commented Apr 1, 2025

Hi @tomasaschan - are you still planning on breaking down this PR into a fewer smaller ones? if not we can have someone pick it up and make sure commits are co-authored with your email.

@tomasaschan
Copy link
Contributor Author

@a-hilaly Yes, I've been meaning to follow up on this! But I've held off for a couple of reasons - partly because I've been swamped at work, but also because this question in Slack never really got answered.

In short: this PR uses https://github.com/B1NARY-GR0UP/nwa to manage license headers, but in the Community Meeting a couple of weeks ago we discussed using https://github.com/google/addlicense/ instead; I'm thinking google/addlicense#173 is somewhat of a blocker for that, and want input from the maintainers on how to proceed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants