Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
karstengresch opened this issue Apr 3, 2019 · 5 comments

Comments

@karstengresch
Copy link

@karstengresch karstengresch commented Apr 3, 2019

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

  1. 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
Copy link
Contributor

@openshift-bot openshift-bot commented Jul 2, 2019

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
Copy link
Author

@karstengresch karstengresch commented Jul 3, 2019

This issue is as fresh as the morning dough.

@karstengresch
Copy link
Author

@karstengresch karstengresch commented Jul 3, 2019

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
Copy link
Contributor

@adambkaplan adambkaplan commented Jul 3, 2019

/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
Copy link
Author

@karstengresch karstengresch commented Jul 3, 2019

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants