operator-sdk generate should not depend on Dockerfile existence

[nrvnrvn]

Bug Report

What did you do?

# make operator-sdk think the `build` directory does not exist.
$ mv build{,1}
$ operator-sdk generate k8s --verbose && operator-sdk generate openapi --verbose
DEBU[0000] Debug logging is set                         
FATA[0000] must run command in project root dir: project structure requires build/Dockerfile
$ mkdir build
$ touch build/Dockerfile
$ operator-sdk generate k8s --verbose && operator-sdk generate openapi --verbose
DEBU[0000] Debug logging is set                         
INFO[0000] Running deepcopy code-generation for Custom Resource group versions: [k8s:[v1alpha1], ] 
INFO[0010] Code-generation complete.                    
DEBU[0000] Debug logging is set                         
INFO[0000] Running OpenAPI code-generation for Custom Resource group versions: [k8s:[v1alpha1], ] 
INFO[0025] Created deploy/crds/k8s_v1alpha1_redis_crd.yaml 
INFO[0025] Code-generation complete.

Dockerfile is not needed for generating deepcopy and openapi files. Yet if it does not exist (or the whole build directory) it stops operator-sdk from proceeding.

Possible Solution
Remove the Dockerfile dependency.
genutil will fail anyway if it does not find the pkg/apis directory

operator-sdk/cmd/operator-sdk/internal/genutil/genutil.go

Line 35 in 21668fa

return nil, fmt.Errorf("could not read pkg/apis directory to find api Versions: %v", err)

Why is it needed?
for those cases when images are built using third-party tools not relying on Dockerfiles

[estroz]

@nrvnrvn this requirement will be removed once #1804 is implemented.

[camilamacedo86]

HI @nrvnrvn,

As described in the comment #2054 (comment) was decided not to move forward with this request. The reason for that is because we are looking for changes in the design to give more flexibility to our users. Then, for customizations like this one, we would like to suggest the usage of controller-gen directly by a Makefile. Following an example of a Makefile with targets to generate/update the CRD's in the SDK structure.

# Produce CRDs that work back to Kubernetes 1.11 (no version conversion)
CRD_OPTIONS ?= "crd:trivialVersions=true"

# Get the currently used golang install path (in GOPATH/bin, unless GOBIN is set)
ifeq (,$(shell go env GOBIN))
GOBIN=$(shell go env GOPATH)/bin
else
GOBIN=$(shell go env GOBIN)
endif

# Generate manifests e.g. CRD, RBAC etc.
manifests: controller-gen
	$(CONTROLLER_GEN) paths=./... crd:trivialVersions=true output:crd:artifacts:config=deploy/crds

# find or download controller-gen
# download controller-gen if necessary
controller-gen:
ifeq (, $(shell which controller-gen))
	go get sigs.k8s.io/controller-tools/cmd/controller-gen@v0.2.0
CONTROLLER_GEN=$(GOBIN)/controller-gen
else
CONTROLLER_GEN=$(shell which controller-gen)
endif

Then, when the command make manifests be called the CRD's in the path deploy/crds will be created/updated.

For further information about how to use the controller-gen as its options/commands see its [docs]
(https://book.kubebuilder.io/reference/controller-gen.html).

I am closing this issue, however, please feel free to re-open if you feel that it is required.

[nrvnrvn]

thank you very much. Will follow this example.

[camilamacedo86]

Hi @nrvnrvn,

Really thank you for your reply. Also, I'd like to recommend you keep the Dockerfile which is created automatically by the SDK in order to keep it sample and you still be able to use its commands since many of them will ensure that it is in the root dir by checking it. Then, customized what would you like as the example provided.

I hope that this info can be helpful to you.