-
Notifications
You must be signed in to change notification settings - Fork 121
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: add gitlab support #545
base: main
Are you sure you want to change the base?
Conversation
✅ Deploy Preview for endearing-brigadeiros-63f9d0 canceled.
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #545 +/- ##
==========================================
+ Coverage 56.96% 58.31% +1.35%
==========================================
Files 46 48 +2
Lines 1566 1605 +39
==========================================
+ Hits 892 936 +44
+ Misses 674 669 -5 ☔ View full report in Codecov by Sentry. |
@msagi - since the wonderful @eddie-knight contributed automated releases, are you able to take a look at the latest status check failure? All PRs will not require a valid label prior to merge. This ensures that we can automate our semantic versioning based on the chosen and agreed titles of improvements, i.e. fix, feature, etc. |
fixed @JamieSlome |
hi @JamieSlome , would you like me to make any further changes? |
"type": "object", | ||
"properties": { | ||
"path": { "type": "string"}, | ||
"url": { "type": "string"}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have type url
?
"path": "/github.com", | ||
"url": "https://github.com", | ||
"enabled": true | ||
}, | ||
{ | ||
"path": "/gitlab.com", | ||
"url": "https://gitlab.com", | ||
"enabled": true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like your proposed configuration. Would it not be better to recommend /github
and /gitlab
? I realise that this is configurable so doesn't really matter and gives control and choice to the developer.
@@ -58,7 +58,7 @@ By default the clone of your repository will communicate with GitHub. To change | |||
|
|||
```bash | |||
git remote -v | |||
git remote set-url origin http://localhost:8000/<YOUR-GITHUB-USERNAME>/git-proxy.git | |||
git remote set-url origin http://localhost:8000/github.com/<YOUR-GITHUB-USERNAME>/git-proxy.git |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
git remote set-url origin http://localhost:8000/github.com/<YOUR-GITHUB-USERNAME>/git-proxy.git | |
git remote set-url origin http://localhost:8000/github/<YOUR-GITHUB-USERNAME>/git-proxy.git | |
git remote set-url origin http://localhost:8000/gitlab/<YOUR-GITLAB-USERNAME>/git-proxy.git |
@msagi - getting some breaches in the UI ( This is a fabulous PR and love the way you've implemented multiple endpoint support at the same point. This is very desirable. The updates to the UI should be fairly trivial as there only a few hyperlinks here and there that directly reference GitHub.com. Still need to do a more in-depth review of the PR but a great start for now! |
@@ -94,8 +94,8 @@ const cancel = async (id, logger) => { | |||
const canUserCancelPush = async (id, user) => { | |||
return new Promise(async (resolve) => { | |||
const pushDetail = await getPush(id); | |||
const repoName = pushDetail.repoName.replace('.git', ''); | |||
const isAllowed = await repo.isUserPushAllowed(repoName, user); | |||
const repoUrl = pushDetail.repo.url; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about pre-existing repositories using the repoName
property in the database? We need to think about how the update propagates to the previous data model and its impact on already stored properties in DB.
@@ -34,6 +34,22 @@ exports.getRepo = async (name) => { | |||
}); | |||
}; | |||
|
|||
exports.getRepoByUrl = async (url) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Keep me honest, but can we not enforce uniqueness with organization
, name
and provider
, i.e. zsh-org
, zsh
and gitlab
.
Can we take advantage of the fact that both GitHub and GitLab follow the same naming convention for repositories and enforce uniqueness this way?
GitHub: finos
, git-proxy
, github
GitLab: zsh-org
, zsh
, gitlab
return new Promise(async (resolve, reject) => { | ||
const repo = await exports.getRepo(name); | ||
const repo = await exports.getRepoByUrl(url); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again, same point here - this is fine moving forward for updated data properties but what about previous stored data? Do we need a transformer?
const repoUrl = pushDetail.repo.url; | ||
const isAllowed = await repo.isUserPushAllowed(repoUrl, user); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same point as the above comments here.
@@ -15,6 +15,11 @@ exports.getRepo = async (name) => { | |||
return collection.findOne({ name: { $eq: name } }); | |||
}; | |||
|
|||
exports.getRepoByUrl = async (url) => { | |||
const collection = await connect(cnName); | |||
return collection.findOne({ url: { $eq: url}}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
return collection.findOne({ org: ..., repo: ..., platform: ... })
Thoughts? We should probably step back a little and define a data model for repository together that will serve us well moving forward and isn't too opinionated. I am not sure about URL as only as this is quite un-atomic in its nature and includes content that we don't need in DB, i.e. https
, ://
- I feel like it can be broken down but happy to hear otherwise of course.
const parsedUrl = url?.match(GIT_URL_REGEX); | ||
if (parsedUrl) { | ||
this.url = url; | ||
this.protocol = parsedUrl[1]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this required?
this.project = repo.project; | ||
this.repoName = repo.name; | ||
this.url = repo.url; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice 👍
Fix #511 .
This is my first stab at adding multi host support to GitProxy. The main idea behind it is: not to lose the original git host during repointing the repo to GitProxy via
git remote set-url
command but keep the it in the repointed url as the first path segment, e.g.Since the original git host is preserved, specific routes can be configured (in
proxy.config.json
) connecting the first path segment to the original host, e.g.I've added GitHub and GitLab repos to the authorisedList and tested
git push
with both host, works fine.GitHub.com is hardcoded in several places, and whilst the proxy now supports GitHub and GitLab too, perhaps we shall sit down and chat how we can evolve the UI component (e.g., GitHub account is hardcoded, etc.) forward.
Note: due to multi host support, the
project/name
is not unique ID any more. A repo can uniquely identified only by its URL, e.g.https://gitlab.com/finos/git-proxy.git
@abinash2512 @JamieSlome - let me know your thoughts