feat: Add Gitea support #4229
feat: Add Gitea support #4229
Conversation
|
Small update for those keeping track: @florianbeisel found my PR and had also started work on his own version for this issue. After contacting me, we decided to work together on this PR. |
This changes adds support for Gitea Webhook Signatures by wrapping the function from the Gitea SDK and calling it from `handleGiteaPost()`.
1.22 as in the previous go.mod is a development version. When referencing a minimum release version the correct format is 1.22.0
Apparently there's no max comment length in Gitea at this point in time.
Integration of mvdkleijn/atlantis and florianbeisel/atlantis efforts
|
Yes, same pattern as the Atlantis GitHub and GitLab clients. Take a look at them. |
|
Hmmm... I don't really like the idea of putting the Gitea REST endpoints in debug logging statements which I believe is what you're suggesting. That would mean having to update the statements anytime the API changes right? I feel like that kind of defeats the purpose of using an SDK. What would be an option... I could check if logger is set to Debug level and in that case use the SDK's SetDebugMode() function? That would put the SDK in debug level? |
|
The 'SDK' is just a thin wrapper around the Gitea API, exactly the same as the GitLab and GitHub Go packages used by Atlantis. The endpoints will be fixed. When there are issues, without a way of seeing the API return codes, it will be very difficult to work out what is happening. We have been through this pain with GitHub and GitLab. The verbose logging within Atlantis commands relies on debug lines being written to the logger irrelevant of whether the server is running with the debug log-level. |
|
Perhaps use the SetDebugMode method in the Gitea SDK to enable debug mode directly? |
|
That's what I suggested earlier but that's apparently not acceptable. I'll revisit this either tonight or tomorrow after I'm done pulling cables. |
|
@X-Guardian I still do not agree, but apparently the recommendation is mandatory. I added the requested debug statements. |
|
Hey all / @nitrocode is this still waiting for / need something? |
|
Hi @mvdkleijn. Please fix the merge conflict and request a review from x-guardian. |
|
@X-Guardian I've added the requested logging, was there anything else that stood out? I'll fix the merge conflict (only small conflict in go.sum) tonight when I have proper access. |
|
@mvdkleijn: the merge conflict should be fixed now |
|
I will finish up the review tonight and coordinate with @X-Guardian |
To clarify, when you use the Atlantis commands in a PR comment, you can pass a "verbose" flag that will append all logging output to the comment response. This includes log events that are debug level, even if the Atlantis server configuration is not set to debug. It also appears that Otherwise, the code looks good! Thank you both for the time/effort to implement support for Gitea. The community will greatly benefit and appreciate the support. |
GenPage
removed
waiting-on-review
|
Thanks @GenPage and @X-Guardian for the context on the debug statements and where they are being used in practice. This has cleared up a few things for me. I don't want to speak for @mvdkleijn but I still would like to give some final context - though I believe we're now all on the same page here. I initially had reservations about the approach to debug logging. Our decision to rely on the SetDebugMode function was based on our understanding and discussions at the time. However, I acknowledge that at least my knowledge was incomplete, especially regarding the For me implementing support for Gitea was a significant effort and my biggest contribution to any project really and I am glad to have been a part of it. Y'alls feedback has been invaluable in steering this PR in the right direction (or keeping it on track). So thank you again for creating a welcoming atmosphere and seeing this through to completion. I will be looking forward to contribute tp the project again should something come up |
|
Hi there @GenPage , @X-Guardian , @nitrocode and others, I'd like to echo @florianbeisel 's sentiment with regards to the friendly reception we received when working on this PR. One aspect I appreciate for example is that the PR did not "hang in limbo" too long as it were, since the longer a PR takes to get reviewed, the more difficult it is to manage for the creator in my personal experience. The requirement for and clarification of the logging certainly helps with understanding and as such is definitely appreciated. Sometimes one can get too focused on specific parts too keep an eye on the total. Though on occasion I had to find time in between family life due to stuff, as no doubt goes for others here too... I feel happy that we could contribute this to the community. I'd also like to say that working together with @florianbeisel was a very nice experience from my point of view. For example: we managed to more quickly respond to feedback because of the co-op when one of us was temporarily occupied. The co-op was much appreciated; thanks for the experience Florian. Like Florian I fully intend to support this code and (time permitting) work on other code as well. Though maybe I'll restrict myself to before 00:00 at night next time Florian. (^_^) |
what
Addition of Gitea client in order to close #3538
A functionally complete implementation of a client for Gitea, with the sole exception being the listing of teams that a user is a member of. However, that's not uncommon for other clients.
It was tested manually against both a Gitea and a Forgejo install. Automated tests were limited to the basics. A large part of the implementation uses the Gitea SDK.
why
See #3538
references
ghcr.io/mvdkleijn/atlantis:devtesting
Also: manual testing by @florianbeisel and @mvdkleijn against Gitea and Forgejo