Feature Request: Gitlab Support

[freexploit]

Is there any plans to support gitlab on any level?

[weilbith]

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? 🤔

[pwntester]

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]

@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]

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.