bundle.Dockerfile path should be parameterized

[vaibhavjainwiz]

Feature Request

bundle.Dockerfile path should be parameterized

Describe the problem you need a feature to resolve.

Currently bundle.Dockerfile by default generates at root directory of project.

Olm also expect dockerFile along the bundle dir.see

Currently we have to copy this file manually and edit the relative path of the content like manifest and metadata path.

Describe the solution you'd like.

It would be better if we could define --bundle.Dockerfile path and its name as input arg to operator-sdk generate bundle cmd

/language go

[estroz]

@vaibhavjainwiz that step you linked is an intermediate step in converting your packagemanifests to a bundle format. At the end of the conversion process, you should have a bundle.Dockerfile at the project root.

/triage support /language go

[vaibhavjainwiz]

@estroz Currently bydefault it always generates bundle.Dockerfile in project root. After its generation I have to manually copy it from project root to bundle folder where other metadata & menifest folder present. It would be better if we could pass output dir of bundle.Dockerfile to operator-sdk generate bundle cmd so that we don't need to do that manual work there.

My other scenerio with this requirement is that I have to make two different bundle for community/product version of my operator. While create bundle using script I am able to define my bundle path using --ouput-dir parameter which works fine to generate manifest and metadata folder but I am not able to handle path of bundle.Dockerfile which overrite existing bundle.Doecker of community version when I run cmd to generate bundle of product.

[estroz]

My other scenerio with this requirement is that I have to make two different bundle for community/product version of my operator.

Ah interesting. This is a totally reasonable use case. I do think this would cause a breaking change in how operator-sdk generate bundle works, so it might have to wait until v2.0.0 unless some good-UX way to handle the current and new cases is devised.

In the meantime, a workaround:

# Makefile

.PHONY: bundle-community
bundle-community: BUNDLE_DIR = bundle-community
bundle-community: bundle

.PHONY: bundle-build-community
bundle-build-community: BUNDLE_DIR = bundle-community
bundle-build-community: bundle-build

.PHONY: bundle-product
bundle-product: BUNDLE_DIR = bundle-product
bundle-product: bundle

.PHONY: bundle-build-product
bundle-build-product: BUNDLE_DIR = bundle-product
bundle-build-product: bundle-build

.PHONY: bundle
bundle: manifests kustomize
	operator-sdk generate kustomize manifests --interactive=false -q
	cd config/manager && $(KUSTOMIZE) edit set image controller=$(IMG)
	mkdir -p $(BUNDLE_DIR)
	cd $(BUNDLE_DIR) && $(KUSTOMIZE) build ../config/manifests | operator-sdk generate bundle -q --output-dir . --package my-operator --overwrite=false --version $(VERSION) $(BUNDLE_METADATA_OPTS)
	operator-sdk bundle validate ./$(BUNDLE_DIR)

.PHONY: bundle-build
bundle-build:
	docker build -f $(BUNDLE_DIR)/bundle.Dockerfile -t $(BUNDLE_IMG) $(BUNDLE_DIR)

By the way this was brought up before, in #3696.