oc new-app behaviour

[mjudeikis]

Behaviour is different how oc new-app works. The suggestion is to make it consistent in few next releases:

case 1:

1. when using syntax ~ code detection is not done as components are not parsed at that time yet. It might be not intentional in the first place, but now users use it when they want to force repository or image
   oc new-app openshift/ruby:latest~https://github.com/openshift/fakerepo.git --loglevel=4
   just to generate objects.

2. When using flags syntax same repos fails because code detection kicks in and git is being used for it.

oc new-app --image-stream=openshift/ruby:latest --code=https://github.com/openshift/fakerepo.git
Username for 'https://github.com':

similar example for open repo:
oc new-app --image-stream=openshift/ruby:latest --code=https://github.com/openshift/ruby-hello-world --loglevel=4 - all succ

The consequence is that syntax behaves differently because where code detection is being done before sorting out content.

So if users want to use flags and cant use ~ (example crazy keyboards where ~ is not present!, Some of our trainers raised this kind of bug before, as they cant use ~ ). But flags trigger to use code detection and they can use it straightforward.

Case 2:

If you want to use private git repo and just generate build config and use flags:

 [root@default ~]# oc new-app --image-stream=openshift/ruby:latest --code=https://github.com/mjudeikis/ocpdeployer.git --source-secret=basicsecret 
Username for 'https://github.com':

Im still being asked to enter my github password (for our git implementation and code detection.)

if I use ~:
I get all BC generated with required secret input:

oc new-app openshift/ruby:latest~https://github.com/mjudeikis/ocpdeployer.git --source-secret=basicsecret

Suggestion:

instead of trying to create multiple checks for where to do and not to do code detection we add the new flag:
--skip-code-detection or --code-detection=false which would allow to use flag based syntax and "just generate objects"

Optional: as for the next step, we make code detection mandatory for ~ syntax too, so we have a more unified view how we handle parameters.

OR

we document code detection and how it works and say: ~ = --skip-code-detection

This would help to get rid of bugs like:
"How I force my java code with my gradle image"
"why syntax ~ and --code --image-stream behaved differently?

cc: @bparees do we need more to start dicussion?

[bparees]

Optional: as for the next step, we make code detection mandatory for ~ syntax too, so we have a more unified view how we handle parameters.

can't do this since it would potentially break existing users/isn't a compatible change.

we document code detection and how it works and say: ~ = --skip-code-detection

i'd definitely prefer to start with this. document the difference in behavior and move on w/ our lives. We've exhausted enough of your time on this :(

if we get pushback on the doc, we can revisit adding the flag you propose.

for future reference, this is in relation to
https://bugzilla.redhat.com/show_bug.cgi?id=1470374
and
https://bugzilla.redhat.com/show_bug.cgi?id=1534916

[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

[bparees]

/remove-lifecycle stale
/lifecycle frozen

i think we still need to fix the doc here