Kubebuilder v3.0.0 fails without a present "Dockerfile"

[shaneutt]

What broke? What's expected?

In our repository we've moved the Dockerfile out of the directory and the build happens elsewhere, but the kubebuilder CLI does not tolerate this, failing with:

Error: failed to edit project: unable to scaffold with "base.go.kubebuilder.io/v3": open Dockerfile: no such file or directory

Furthermore if the file does exist it checks for a very specific line:

Error: failed to edit project: unable to scaffold with "base.go.kubebuilder.io/v3": can't find "COPY apis/ apis/"

I would expect the CLI by default to be able to tolerate the lack of Dockerfile present, and allow the end user to manually manage the file.

Reproducing this issue

These commands reproduce the problem:

$ cd $(mktemp -d)
$ mkdir test
$ cd test
$ kubebuilder init --plugins go/v3 --domain example.org --owner "Your name"
$ go mod init example.org
$ kubebuilder init --plugins go/v3 --domain example.org --owner "Your name" --skip-go-version-check
$ rm Dockerfile 
$ kubebuilder edit
Error: failed to edit project: unable to scaffold with "base.go.kubebuilder.io/v3": open Dockerfile: no such file or directory

KubeBuilder (CLI) Version

Version: main.version{KubeBuilderVersion:"3.0.0", KubernetesVendor:"1.19.2", GitCommit:"533874b302e9bf94cd7105831f8a543458752973", BuildDate:"2021-04-28T16:23:59Z", GoOs:"linux", GoArch:"amd64"}

PROJECT version

version: "3"

Plugin versions

layout:
- go.kubebuilder.io/v3

Other versions

$ go version
go version go1.16.3 linux/amd64

$ grep controller go.mod
sigs.k8s.io/controller-runtime v0.8.3

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.5", GitCommit:"6b1d87acf3c8253c123756b9e61dac642678305f", GitTreeState:"archive", BuildDate:"2021-03-30T00:00:00Z", GoVersion:"go1.16", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.2", GitCommit:"faecb196815e248d3ecfb03c680a4507229c2a56", GitTreeState:"clean", BuildDate:"2021-01-21T01:11:42Z", GoVersion:"go1.15.5", Compiler:"gc", Platform:"linux/amd64"}

Extra Labels

No response

[Adirio]

The edit command modifies the Dockerfile to use the right API path, so that error is expected.

[shaneutt]

The edit command modifies the Dockerfile to use the right API path, so that error is expected.

Sorry I may not have communicated the point as well as I had hoped to:

The kubebuilder edit subcommand describes itself in this way:

$ kubebuilder edit --help
This command will edit the project configuration.
Features supported:
  - Toggle between single or multi group projects.

So if it's really intended to do more, shouldn't that intended behavior around Dockerfiles be listed or otherwise mentioned?

[camilamacedo86]

Hi @shaneutt,

The CLI tool will look for the files in the specific places that have no way for that discovery where is the place that you move out the Dockerfile. Note that the edit command will edit the default Dockerfile scaffolded to change it accordingly to the multi-group support layout.

Please see the note: https://book.kubebuilder.io/migration/v2vsv3.html#project-customizations

And then, please let us know if it answers your question and if we can close this one.

[shaneutt]

The CLI tool will look for the files in the specific places that have no way for that discovery where is the place that you move out the Dockerfile. Note that the edit command will edit the default Dockerfile scaffolded to change it accordingly to the multi-group support layout

1. does it need to fail?
2. if it does need to fail shouldn't the docs for the command be updated to reflect the Dockerfile related features?

[k8s-triage-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[shaneutt]

It's not fixed, but at least from my perspective it's no longer an issue because of how we've changed the structure of several of our repositories. I have no personal follow-up, but if someone else feels strongly they can re-open.