Bug 1877739

Created attachment 1714411 [details]
customer env screen shot

Only had the error, but the s2i process can be complete.

verified on build 4.6.0-0.nightly-2020-09-28-061045

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 (OpenShift Container Platform 4.6 GA Images), 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-2020:4196

hello

I have also meet this issue on OCP 4.9.10

If I use a git server which customer owned cannot success by S2I on OCP DevConsole, the error is:

"URL is valid but cannot be reached. If this is a private repository, enter a source Secret in advanced Git options"
(I have attach a screenshot on attachment)

This is my git test repository:

http://18.163.74.11:10080/gogs/openshift-php-upload-demo.git

But using oc new-app command line can work well 

bash-4.4 ~ $ oc project test
Now using project "test" on server "https://172.30.0.1:443".
bash-4.4 ~ $ oc new-app http://18.163.74.11:10080/gogs/openshift-php-upload-demo.git
--> Found image dc56c67 (12 days old) in image stream "openshift/php" under tag "7.4-ubi8" for "php"

    Apache 2.4 with PHP 7.4 
    ----------------------- 
    PHP 7.4 available as container is a base platform for building and running various PHP 7.4 applications and frameworks. PHP is an HTML-embedded scripting language. PHP attempts to make it easy for developers to write dynamically generated web pages. PHP also offers built-in database integration for several commercial and non-commercial database management systems, so writing a database-enabled webpage with PHP is fairly simple. The most common use of PHP coding is probably as a replacement for CGI scripts.

    Tags: builder, php, php74, php-74

    * The source repository appears to match: php
    * A source build using source code from http://18.163.74.11:10080/gogs/openshift-php-upload-demo.git will be created
      * The resulting image will be pushed to image stream tag "openshift-php-upload-demo:latest"
      * Use 'oc start-build' to trigger a new build

--> Creating resources ...
    buildconfig.build.openshift.io "openshift-php-upload-demo" created
    deployment.apps "openshift-php-upload-demo" created
    service "openshift-php-upload-demo" created
--> Success
    Build scheduled, use 'oc logs -f buildconfig/openshift-php-upload-demo' to track its progress.
    Application is not exposed. You can expose services to the outside world by executing one or more of the commands below:
     'oc expose service/openshift-php-upload-demo' 
    Run 'oc status' to view your app.


this repository is mirror from github:
https://github.com/christianh814/openshift-php-upload-demo.git

If we use github git repository, can work well

so problem is OCP DevConsole using private Git cannot work, is this a bug on OCP 4.9 ?

Created attachment 1859947 [details]
OCP 4.9 error information screenshot

Created attachment 1859948 [details]
OCP 4.9 using command line work well

Hi Team

The Kevin is from the Red Hat SA team, he meet the issue again on OCP 4.9 , please help to check, Thank you

Hi @kevin,

We looked at this issue and it seems `oc` CLI can use secrets to talk to Github during the detection of builder image. In the UI, we directly talk with the Github APIs for the detection which didn't use any secrets. This is why the builder image detection didn't work in the UI but the build works correctly if you select a builder image explicitly. 

In 4.9, we added a new feature in the detection mechanism where if you add a secret with authentication details, it uses that secret to talk to the APIs. It is supposed to work if you add correct auth details in your secret and select it in the advanced git options. But it seems there's a bug which is why it doesn't work even in 4.9. We'll track this bug separately so that its easier to backport it back to 4.9 and we'll close this current bug as it was not a feature that we supported till 4.8. Here's a ticket to track this - https://bugzilla.redhat.com/show_bug.cgi?id=2053501.

Thanks

As per the @rorai comment above. We are closing this ticket as this feature was not supported till 4.8 and tracking this issue in 4.9 here in ticket https://bugzilla.redhat.com/show_bug.cgi?id=2053501.

Hi, just because the original bug was a real bug and was fixed in 4.6, I think the right resolution should be ERRATA as we fixed, verified, and released the initial fix.