Add option to disable OCI image build

[baijum]

fixes #1599

Description of the change:

Introduce a --without-image for operator-sdk build command to disable building OCI image.

Motivation for the change:

I want to build operator binary without producing OCI image.

[DhritiShikhar]

@baijum Thanks for this change.

[sbose78]

Nice! I wouldn't have to construct my go build.. in the make target now.

[joelanford]

@baijum the SDK team has been talking about the fact that the built-in subcommands that wrap go, docker, and other CLI tools are falling short of the necessary flexibilities to meet all use cases.

So instead of constantly fixing bugs and adding new flags for each new use case that comes up (see #1034, #1271, #1311, #1357, #1419, #1422, #1488, #1489, #1497, #1509, #1535, #1582, #1605), we think it makes more sense to recommend that users that need more flexibility start using Makefiles in their projects so that they have full control.

This has a few benefits to both users and SDK maintainers:

1. Users no longer have to wait for a bug fix or new feature in the SDK to customize their operator builds.
2. Users can more easily tie dependent commands together (e.g. always run code generation before building binaries, and always rebuild binaries before building the Docker image)
3. It makes the SDK much simpler in some areas, so maintainers can spend less time dealing with the complexities of abstracting wrapped go, docker, podman, and buildah commands under one CLI. And more time on core SDK and operator-related features.
4. It aligns more with Kubebuilder, which actually scaffolds a Makefile for go compilations, image builds, code generation, etc.

Going down this path, the SDK will also need to scaffold a Makefile to give users the same default experience as the existing subcommands, so I think that's an area we should start devoting effort toward.

In the meantime, we can definitely help you construct a Makefile that runs the same underlying go and docker commands, if that would be helpful.

What do you think? Does that seem like a reasonable way forward?

[baijum]

@joelanford Makefile based approach would be good. When you design the Makefile, ensure there is a clean way to provide build instruction to up local command.

[hasbro17]

@baijum @joelanford Can we close this if we intend to support additional options like this via a Makefile going forward?

I've created #1655 as the umbrella issue for that discussion.

[jamesphillpotts-fr]

I think it's a shame that this PR was closed rather than merged - it didn't stop the team working towards the makefile solution (which I see still has "Needs Design" label on it, so presumably still isn't near completion), and would solve a number of people's issues (as shown by the number of times this issue is referenced/duplicated). I've had to fork and make a similar change, which is a shame. Would you consider reopening this PR and merging for a 0.12.1 release?