Operator SDK v1.9.0 seems to ignore --output-dir when generating bundle.Dockerfile

[amisevsk]

Bug Report

What did you do?

The behaviour of operator-sdk generate bundle appears to have changed in v1.9.0, producing invalid bundle.Dockerfiles.

What did you expect to see?

In Operator SDK v1.7.2, running operator-sdk generate bundle with the --output-dir deploy/bundle argument produces a bundle.Dockerfile containing the lines

# Copy files to locations specified by labels.
COPY deploy/bundle/manifests /manifests/
COPY deploy/bundle/metadata /metadata/
COPY deploy/bundle/tests/scorecard /tests/scorecard/

What did you see instead? Under which circumstances?

Executing

operator-sdk generate bundle \
  --deploy-dir deploy/deployment/olm \
  --output-dir deploy/bundle \
  --manifests \
  --metadata

outputs manifests and metadata to deploy/bundle/* but the dockerfile contains

# Copy files to locations specified by labels.
COPY bundle/manifests /manifests/
COPY bundle/metadata /metadata/
COPY bundle/tests/scorecard /tests/scorecard/

The bundle directory does not exist

Environment

Operator type:

/language go

Kubernetes cluster type:

OpenShift 4.7

$ operator-sdk version

v1.9.0

$ go version (if language is Go)

go version go1.16.4 linux/amd64

$ kubectl version

Client Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.4", GitCommit:"d360454c9bcd1634cf4cc52d1867af5491dc9c5f", GitTreeState:"clean", BuildDate:"2020-11-11T13:17:17Z", GoVersion:"go1.15.2", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.0+5fbfd19", GitCommit:"5fbfd197c16d3c5facbaa1d7b9f3ea58cf6b36e9", GitTreeState:"clean", BuildDate:"2021-02-17T15:21:33Z", GoVersion:"go1.15.5", Compiler:"gc", Platform:"linux/amd64"}

Possible Solution

Take into account --output-dir when writing bundle.Dockerfile

Additional context

I'm working on updating https://github.com/devfile/devworkspace-operator to use operator-sdk v1.9.0 in order to get OLM webhooks support.

[amisevsk]

Just checked v1.8.0 and issue does not reproduce there

[varshaprasad96]

@amisevsk yes, this is a bug. #5030 would fix it.