Description of problem: "oc new-app" always tries to perform a git pull even with local repo with all info supplied. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Clone a repo locally (ex. https://github.com/openshift/ruby-20-centos) 2. CD to repo 3. run 'oc new-app .' Actual results: oc new-app will still perform a pull, and if the origin URL is unreachable, it will fail. Expected results: Preferably, when pointing to a local repo, oc new-app should not try a pull. At the very least, please at an optional way to skip pulling. Additional info:
Tested with $ oc version oc v1.3.0-alpha.2+cad5478 kubernetes v1.3.0+57fb9ac features: Basic-Auth I cannot reproduce this issue. I cloned a repo and set its origin URL to a fake URL: $ git clone https://github.com/csrwng/simple-ruby.git $ cd simple-ruby $ git remote set-url origin https://blah.blah.blah.com/test/test.git Then invoked new-app: $ oc new-app . Got the following result: --> Found image 5b01527 (7 days old) in image stream "ruby" in project "openshift" under tag "2.3" for "ruby" Ruby 2.3 -------- Platform for building and running Ruby 2.3 applications Tags: builder, ruby, ruby23, rh-ruby23 * The source repository appears to match: ruby * A source build using source code from https://blah.blah.blah.com/test/test.git#master will be created * The resulting image will be pushed to image stream "test:latest" * Use 'start-build' to trigger a new build * This image will be deployed in deployment config "test" * Port 8080/tcp will be load balanced by service "test" * Other containers can access this service through the hostname "test" --> Creating resources with label app=test ... imagestream "test" created buildconfig "test" created deploymentconfig "test" created service "test" created --> Success Build scheduled, use 'oc logs -f bc/test' to track its progress. Run 'oc status' to view your app.
$ oc version oc v3.3.0.8 kubernetes v1.3.0+57fb9ac Can't reproduce this issue with same way in comment #1
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-2016:1933