-
Notifications
You must be signed in to change notification settings - Fork 176
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
base: main
Are you sure you want to change the base?
Conversation
13333f8
to
3f3ae20
Compare
@a-hilaly The tests are now failing because the bump of |
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. Most of the local development workflow should now be covered by 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 (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!) |
9643011
to
79e3f03
Compare
(There; rebased to get rid of conflicts in |
This relies on yet unreleased features of controller-runtime, but it will we'll be able to roll forward to the next patch release as soon as one that contains both kubernetes-sigs/controller-runtime#3135 and kubernetes-sigs/controller-runtime#3137 is released.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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"), |
There was a problem hiding this comment.
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
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. |
@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. |
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
, throughgo 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
toolchainWe should be able to run tests with
go test ./...
, generate code and other artifacts usinggo 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
andgovulncheck
to run through that, but where possible we should try to avoid using other CLI entrypoints thango
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 ofkustomize 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
go generate
attribution-gen
withgo generate
controller-gen
withgo generate
controller-gen
emit only the stuff we care about (CRDs, perhaps manager config, but not RBAC) and emit it into the Helm chart directlygo.mod
and get rid ofhack/toolchain.sh
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#3135go tool ko
; also set up Github Actions to do it in CI/config
directory in favor of/helm
as the source of truth for how to install kroWe'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 ofgo.mod
, or in the new filescodegen.go
and.nwa-config.yaml
, is generated.