syndesisio / syndesis-rest

The API for Syndesis - a flexible, customizable, cloud-hosted platform that provides core integration capabilities as a service. It leverages Red Hat's existing product architecture using OpenShift Online/Dedicated and Fuse Integration Services.
https://syndesis-staging.b6ff.rh-idev.openshiftapps.com/api/v1/
Apache License 2.0
6 stars 17 forks source link

project-generator: full repo URL in readme #288

Closed dsimansk closed 7 years ago

dsimansk commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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

jimmidyson commented 7 years ago

Oops 😣

KurtStam commented 7 years ago

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

rhuss commented 7 years ago

There is currently a catch-22:

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

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 commented 7 years ago

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