Support gitea
ibotty opened this issue · comments
it would be great to also support gitea.
Hi @ibotty !
Yes, it would be great. But to be really honest I must say that we (as a Packit team) will probably not have the bandwidth to work on that, but we can definitely help anyone willing to work on that. We can also consider doing this as a part of projects like GSOC or RHOSC and provide a mentor for that. Also, this does not need to be full support from the very start.
Would you be interested in helping with that? And can you please share with us shortly your use case?
We have a few internal projects written in python that interact (pretty poorly) with gitea. I am pushing the team to use a library. And I would certainly like this library to be one that is used in production with others to shake out bugs.
Apart from that, from a free software and open infrastructure perspective I'd like the free software world to support many different git forges and not only the commercial ones.
I will not have much time to work on this myself though. Sorry about that.
I see. Thanks for the details.
Apart from that, from a free software and open infrastructure perspective I'd like the free software world to support many different git forges and not only the commercial ones.
I agree and we are open to any forge --the current three were what we needed for our service. Note that I wouldn't consider Pagure as a commercial git forge. For our service, it would be nice to support more forgets, but the request needs to be so significant that it's worth spending the time on implementation and maintenance. Until then, It's better to spend our time on other parts of the project...
Hopefully, someone with the interest will help with this support. (And ideally not only with the implementation because keeping the track with the forges needs some time as well.)
On a more technical note, do you have any suggestions for the implementation itself? Is there any library we can use? E.g. for Github we use pygithub library, for GitLab python-gitlab and for Pagure, we do the communication on our own since the `libpagure isn't ideal for us.
I did not want to imply that pagure is a commercial git forge. It's not.
Regarding a library, I don't know. I personally only interacted with gitea's API via HTTP. The team is using openapi-generated documentation. There is a list of SDKs on gitea's documentation page: https://gitea.com/gitea/awesome-gitea#user-content-sdk
Hi, I have a self-hosted Gitea instance and also tried to use its API on few occasions. I must admit that they provide »very good« SDK, but just for the Go. On the other hand, with regards to other languages it is »much worse«, from my experience, it influenced switch of the tool to Go.
As for Python, I have found an official SDK and also some suspicious ones like this one that was updated recently.
From the PoV of Packit, I would say the biggest issue is that we cannot rely on any Python dependency, which leaves us with the following options:
-
do the requests manually as we do with Pagure
This case is quite tedious and time-consuming. -
use swagger to generate the API (as the suspicious PyPI package does)
In this case, we would need to mantain the Gitea API on 2 levels:- making sure we have the latest API
- wrapping it in our own „compatibility layer“ (to provide unified API)
However, if you look at this PR (dblueai/giteapy#4), you can notice that even the swagger-generated code introduces a lot of complexity. From my experience, I can also say they have a pretty quick development and since majority of Gitea instances are self-hosted, the issue with backward-compatibility might get out of hand regarding the API.
Hi, we have discussed this feature request within our team last week and have come to a conclusion that we do not have a capacity to work on this. There are few reasons for that decision.
First of all, at the moment we do not have any intentions of providing our CI1 on the Gitea, especially since there is no demand and majority of Gitea instances are self-deployed which means that configuring each of them requires a manual intervention into our deployment from our side. Please try to understand that this library was developed mainly for the purpose of accessing the git forges in a unified way from both our CI1 and CLI2.
Secondly, given that I have a Gitea instance deployed myself, I know that they have a pretty fast iterative development, which would make maintaining of the Gitea support in ogr very demanding on our team.
Last, but not least, we have come to a conclusion that we are willing to accept changes regarding Gitea support, under the label of the „community support“. Therefore, if you are willing to contribute, we will be more than glad to help you out and include your changes in the library.
Thanks for the understanding :)