project-generator: full repo URL in readme

[dsimansk]

Project-generator template should add full URL which would be usable ootb.

Current generated Readme:

$ oc new-app fabric8/s2i-java:2.0.0~testme

Desired state:

$ oc new-app fabric8/s2i-java:2.0.0~https://github.com/<username>/<repository>

$ oc new-app fabric8/s2i-java:2.0.0~https://github.com/dsimansk/testme

[KurtStam]

@dsimansk Can you tell me what the value of your Integration.gitRepo is? As far I understand it this should be set to https://github.com/dsimansk/testme, which then gets used in its entirety for the README.

[dsimansk]

This one for instance https://github.com/dsimansk/testme

The issue is that oc new-app needs complete URL to use s2i properly(clone & build), but {{gitRepo}} variable represents just name of repository instead of something like {{gitRepoUrl}}.

[KurtStam]

So it looks like we walked into demo-ware: https://github.com/redhat-ipaas/ipaas-rest/pull/160#pullrequestreview-26249892.

[jimmidyson]

Oops 😣

[KurtStam]

@rhuss is going to work on https://github.com/redhat-ipaas/ipaas-rest/issues/162, that should address this issue.

[rhuss]

There is currently a catch-22:

• For creating the project files (including the README) we need the gitCloneUrl for inclusion.
• We get the gitCloneUrl only after we have created the Git repo and added the projects files, which currently is an atomic step.

I could break up the atomic operation of creating the repo + adding the files as separate steps:

• Create repo for the current user, get URL (if not existing)
• Create the in-memory project files, with the URL as template param value
• Add / Update files in the repo

The alternative is to "calculate" the URL in the scheme https://github.com/<user>/<repoName> where the user is the current user for the API account.

My question is currently what is whether the user part is supposed to stay a single name (as determined through the GitHub API access account), or whether there are already plans to make it more multi-tenant ?

Which of the two solutions is the preferred one ? The second is simpler to implement. For multi tenancy we would have to change both solutions anyway. // @jimmidyson @KurtStam

[jimmidyson]

Multitenancy will require a much broader rethink anyway so the second option sounds fine for now to get this moving.