oc new-app/oc new-build parameter for not auto triggering build process: oc new-(app|build) --suppress-build

[karstengresch]

Problem description

When running oc new-app or oc new-build, this automatically triggers a build creation.
Especially Quarkus (and golang) tooling makes patching the BuildConfig necessary, see https://github.com/quarkusio/quarkus/blob/master/docs/src/main/asciidoc/openshift-s2i-guide.adoc

Both waiting for the first build to fail (could take 15 mins or more) or combining oc create ... with && oc cancel-build (can fail if build hasn't started yet) aren't really useful approaches.

In the spirit of the abandoned #15429, I suggest adding a parameter

--suppress-build

that just cancels the first build execution.

Alternatively, the documentation could be enhanced in a way that shows how to patch the build config with the create commands (if possible).

Version

v3.11

Steps To Reproduce

1. Run e.g.

oc new-app quay.io/quarkus/centos-quarkus-native-s2i~{quickstarts-clone-url} --context-dir=getting-started --name=quarkus-quickstart-native

2. Try to do this w/o triggering the build creation.

Current Result

You cannot prevent OCP from building.

Expected Result

You can disable the build trigger with a parameter.

Especially for a good Quarkus adoption this is IMHO a crucial topic.

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

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

/lifecycle stale

[karstengresch]

This issue is as fresh as the morning dough.

[karstengresch]

B.t.w. closing issues with a bot because there is no activity on them is IMHO bad practice: this can lead to suppressing critical problems just because nobody in the project's takes over responsibility.

[adambkaplan]

/remove-lifecycle stale
/lifecycle frozen

We use the similar bots as upstream Kubernetes - the feature lifecycle bot ensures that old issues get triaged.

@openshift/openshift-team-developer-experience

[karstengresch]

@adambkaplan Doh, reading GH comments on mobile devices leads to ignorance of hints like "commenting /remove-lifecycle stale" for me. Sorry.

Thanks for adding the comment.

Regarding the bot: Especially when issues come in from the wild, this procedure might be quite risky as devs who submitted a valid issue could move along/pass away/loose focus/whatever.

IMHO a better approach would be to allow the bot adding the labels (and finally closing the issue) after sbdy (maybe to be defined more specifically) from the project team has added a label like e.g. "lifecycle/acknowledged" or else.

If I wanted attacking Kubernetes installations, now I knew where I had to look.