jx boot failing on GHE with latest CLI due to failing GET request

[tomfrenken]

Summary

With the latest CLI I receive the following errors on GitHub Enterprise:

error: handle dev environment repository: creating remote for dev environment environment-jx-eval-01-dev: duplicating https://github.com/tomfrenken/jenkins-x-boot-config to jx-test-org/environment-jx-eval-01-dev: getting repo for https://github.com/tomfrenken/jenkins-x-boot-config: failed to get repository tomfrenken/jenkins-x-boot-config due to: GET https://github.tools.sap/api/v3/repos/tomfrenken/jenkins-x-boot-config: 404 Not Found []
error: failed to interpret pipeline file jenkins-x.yml: failed to run '/bin/sh -c jx step verify env' command in directory '.', output: ''

I previously forked the repo and changed the files, the jx-requirements.yaml looks like this:

cluster:
  clusterName: ""
  environmentGitOwner: ""
  environmentGitPublic: false
  gitKind: github
  gitName: ghe
  gitServer: https://github.tools.sap
  project: ""
  provider: gke
  zone: ""
gitops: true
environments:
- key: dev
- key: staging
- key: production
ingress:
  domain: ""
  externalDNS: false
  tls:
    email: ""
    enabled: false
    production: false
kaniko: true
secretStorage: local
storage:
  logs:
    enabled: true
    url: ""
  reports:
    enabled: true
    url: ""
  repository:
    enabled: true
    url: ""
versionStream:
  ref: "master"
  url: https://github.com/jenkins-x/jenkins-x-versions.git
webhook: lighthouse

Steps to reproduce the behavior

Fork the boot-config, change values to work with GHE, run jx boot

Expected behavior

It works

Actual behavior

It doesn't

Jx version

The output of jx version is:

NAME               VERSION
jx                 2.0.1133
Kubernetes cluster v1.13.11-gke.14
kubectl            v1.17.1
helm client        Client: v2.16.1+gbbdfe5e
git                2.25.0
Operating System   Mac OS X 10.15.2 build 19C57

Jenkins type

• Serverless Jenkins X Pipelines (Tekton + Lighthouse)
• Classic Jenkins

[abayer]

I rewrote this logic again in 2.0.1134 - mind giving it another try? That said, I have a feeling something else may blow up after this point. I’m gradually struggling my way through getting boot + gitops actually working with non github.com providers, and there are a surprising number of little gotchas.

[tomfrenken]

Sure I'll try it in a few hours again 👍

[abayer]

So we actually nailed this one down last night - the bootConfigURL was set to a non-default repo on github.com, so it slipped through my logic for not using the default provider. I will fix. =)