search

pwntester / octo.nvim

Edit and review GitHub issues and pull requests from the comfort of your favorite editor
MIT License
2.42k stars 136 forks source link

Feature Request: Gitlab Support #138

Closed freexploit closed 3 years ago

freexploit commented 3 years ago

Is there any plans to support gitlab on any level?

weilbith commented 3 years ago

I think that's not easily possible. This plugin builds fully around the GitHub CLI tool. I don't think they will aim to support GitLab as well. On the other side the architecture of this plugin is not structured so that it would be easily possible to add an alternative "endpoint". Especially because the data objects of the GitHub API are spread all other the place.

@pwntester your statement? :thinking:

pwntester commented 3 years ago

The code is tightly coupled to the objects returned by the GitHub GraphQL API. It should be possible to refactor the code so that the gh module invokes different queries for GitLab and then maps the returning objects to the ones expected by Octo, but that's something Im not planning to do in the short term. PRs are welcome though :)

AckslD commented 3 years ago

@weilbith @pwntester gitlab support would be great! To my knowledge the glab-cli has a quite similar API to gh. I don't know anything about the internals of octo but maybe a similar approach to how it's done in cmp-git could be taken? Has anyone look into this further since above? :)

weilbith commented 3 years ago

I just checked out the GraphQL reference documentation of both APIs. On a first gaze they look quite similar. But some details are different. Here and there is a field missing or has slightly different type. So I think the devil is in the details. Unfortunately there are no tests to just try it and exchange the executed binary. You would need to test everything manually and really have an eye for the details. Though I agree with @pwntester that this plugin should actually be refactored in such a case and put an abstract interface in place. This is necessary to decouple the core functionality of this plugin from the dependencies that are used to communicate with the repository service provider. This interface would then be implemented for GitHub and GitLab. In theory also others like Mango. An important thing here is that we would need to add custom struct definitions for internal. Atm the foreign objects get used all other the place and create an huge dependency issue. But LuaJIT is also untyped and it is little nightmare to use proper typing here. At least in a developer supportive manner. This would require to use Teal or alternatives. After all: it might work semi optimal with minimal changes by just using a different binary. The proper solution requires an immense amount of refactoring. I would love to see this. But I think all parties lack in time to do so.