✨ feat(go/v4): add support for custom boilerplate path

[ardikabs]

Related to #3697

Description

Add support to a custom boilerplate path for the base.go.kubebuilder.io/v4 plugin.

The following are changes involved in this feature request:

1. add --boilerplatePath flag to kubebuilder --plugin "base.go.kubebuilder.io/v4" init
2. add --boilerplatePath flag to kubebuilder --plugin "base.go.kubebuilder.io/v4" create api
3. add --boilerplatePath flag to kubebuilder --plugin "base.go.kubebuilder.io/v4" create webhook

Expectation

After applying this feature, you can customize the boilerplate file path to any path other than the default (hack/boilerplate.go.txt), like the following examples:

• Init

kubebuilder init --plugins base.go.kubebuilder.io/v4 --license apache2 --owner example.com --boilerplatePath tools/hack/boilerplate.go.txt

• Create API

kubebuilder create api --controller=false --group example --kind CustomPlugin --version v1alpha1 --boilerplatePath tools/hack/boilerplate.go.txt

• Create Webhook

kubebuilder create webhook --group example --kind CustomPlugin --version v1alpha1 --defaulting --programmatic-validation --boilerplatePath tools/hack/boilerplate.go.txt

[k8s-ci-robot]

Welcome @ardikabs!

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

I'm waiting for a kubernetes-sigs 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: ardikabs
Once this PR has been reviewed and has the lgtm label, please assign camilamacedo86 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

[ardikabs]

As I am new to the kubebuilder codebase, please be advised on where I should put a test for this feature. Thanks!

[camilamacedo86]

The change cannot be made within the API command. Doing so would mean that we would be able to define a different value for each API.

If we allow customization, it must be done via the kubebuilder init and kubebuilder edit commands. Additionally, the path must be stored in the PROJECT file.

Could you please take a look at it and see if you have any concerns?

[varshaprasad96]

+1 to what @camilamacedo86 mentioned. Allowing boilerplate configured differently during these commands would lead to confusion of:
(1) Single project having multiple licenses.
(2) Certain commands like create webhook also modify existing files - causing conflict on boilerplate usage.
Though (1) is still possible, its a scenario where user can manually change the boilerplate based on their needs as it seems to be an edge case.

[camilamacedo86]

As I am new to the kubebuilder codebase, please be advised on where I should put a test for this feature. Thanks!

See the e2e tests: https://github.com/kubernetes-sigs/kubebuilder/tree/master/test/e2e

To create the tests that would be new dir with a test like the others just to check the layout after the change.
Following the steps that I see here:

• create a project kb init --header-file-path=
• then, ensure that the hack/dir is not created and instead the new path
• after that, ensure that the makefile is updated accordingly
• Call generated and ensured that the header of the files had the header of the path informed.
  Lastly, it is properly configured in the ProjectConfig via a new spec.

[camilamacedo86]

Hi @ardikabs

I am closing this one since, as we spoke if we would like to add this feature, we need to add it for the init|edit subcommand and keep the data stored in the PROJECT file so that it can be used across since it is valid for the whole project. We cannot have one specific config for each API.

Therefore, I hope that you do not mind if we close this one, and please feel free to raise a new PR with the proposed solution or reopen this one.