Description of problem: Choosing one of the standard JBoss EAP/JWS templates and then changing the git repo address, then removing (wiping) the git reference and context directory (i.e. setting the field to empty) does *not* alter the default fields. This means when the build starts it has not removed the git reference and context directory, causing an instant build (pull) fail. This is very misleading from a UI perspective. Version-Release number of selected component (if applicable): OCP 3.9.31 How reproducible: Always Steps to Reproduce: 1. Add to project 2. Select an example EAP template (i.e. 7.1 without https) 3. Change the git repo (i.e. https://github.com/utherp0/os-rest-comntainerview 4. Wipe the 'context directory' and 'git reference' input fields 5. Click Next to start the build Actual results: Build instantly fails due to the inherited 'context directory' and 'git reference' being added to the buildconfig even though the fields were wiped on the input page Expected results: Empty fields in the input page should result in no information for 'context directory' and 'git reference' being added to the buildconfig Additional info:
Do you have service catalog and template service broker installed? I'm not seeing this behavior through the normal template flow.
Created attachment 1469925 [details] Processed template request clears fields I also checked the build config that was created, and it didn't have the context dir or git ref set.
I was able to reproduce against template service broker. The parameters the UI creates is: ```json {"APPLICATION_NAME":"eap-app","AUTO_DEPLOY_EXPLODED":"false","IMAGE_STREAM_NAMESPACE":"openshift","MAVEN_ARGS_APPEND":"-Dcom.redhat.xpaas.repo.jbossorg","MEMORY_LIMIT":"1Gi","SOURCE_REPOSITORY_URL":"https://github.com/jboss-developer/jboss-eap-quickstarts"} ``` Note that we cannot set these fields explicitly to "" because it breaks generated values. (Values are not generated when a parameter is explicitly set to "".) We had to remove these fields from the parameters JSON. See discussion in: https://github.com/openshift/origin/issues/14445 And also the logic here: https://github.com/openshift/origin-web-catalog/blob/e8edb4beebd5b82a4cf41b3ee7baec6e53240b7e/src/components/order-service/order-service.controller.ts#L442-L454 I don't believe there is a fix we can make only in the UI, so this needs to be addressed in the template service broker itself.
Would it make sense from a UI perspective to default the parameters (webpage side) to 'master' and '/' (i.e. -p SOURCE_REPOSITORY_REF="master" -p CONTEXT_DIR="/")? These would work by default.....
*** Bug 1618512 has been marked as a duplicate of this bug. ***
Is anyone fixing this issue whether on template service broker or in the UI? It keeps failing during our workshops and makes us look bad.
Veer we have not worked this issue yet. I'll align to 4.0.0 and we will investigate next sprint, at present I'm not sure what the proper fix should be.
https://github.com/openshift/origin/pull/21371
This bug requires a UI change. Depends on https://github.com/openshift/console/pull/711
Commit pushed to master at https://github.com/openshift/origin https://github.com/openshift/origin/commit/f049170804b05b5652425ab1a26645544407c867 Merge pull request #21371 from johnkim76/BZ1605136 Bug 1605136 - allow empty string values for non-generated parameters
*** Bug 1666672 has been marked as a duplicate of this bug. ***
In v4.0, the UI API is different from v3.9. In this API: api/kubernetes/api/v1/namespaces/.../secrets the parameters can be successfully post. step: 1. select 'eap' template , click 'create instance' 2. Change the git repo to https://github.com/utherp0/os-rest-containerview 4. Wipe the 'context directory' and 'git reference' input fields, then create. I catch the parameters are post and created successfully. "{"ARTIFACT_DIR":"","GENERIC_WEBHOOK_SECRET":"","IMAGE_STREAM_NAMESPACE":"openshift","JGROUPS_CLUSTER_PASSWORD":"","SOURCE_REPOSITORY_REF":"","MAVEN_MIRROR_URL":"","MAVEN_ARGS_APPEND":"-Dcom.redhat.xpaas.repo.jbossorg","AUTO_DEPLOY_EXPLODED":"false","HOSTNAME_HTTP":"","GITHUB_WEBHOOK_SECRET":"","APPLICATION_NAME":"eap-app","MQ_CLUSTER_PASSWORD":"","MQ_QUEUES":"","CONTEXT_DIR":"","MEMORY_LIMIT":"1Gi","SOURCE_REPOSITORY_URL":"https://github.com/utherp0/os-rest-containerview","MQ_TOPICS":""} VERIFIED kubernetes v1.12.4+4dd65df23d Cluster version is 4.0.0-0.nightly-2019-02-26-05433
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:0758