Gitea driver implementation
Hi all,
Under https://review.opendev.org/q/topic:gitea_driver https://review.opendev.org/q/topic:gitea_driver you can find stack of changes for implementing Gitea driver in Zuul. The work is not finished and not all features (from my pov) are implemented, but it already becomes expensive to manage long stack needing to rebase everything due to other parallel interface changes to Zuul. Therefore I would kindly ask Zuul cores to have a look and start giving first core reviews (there are non core reviews slowly coming).
ReleaseNote is supposed to be added once functionality is generally completed and verified. Amount of CRD tests is also to be heavily increased.
We are currently already running productive Zuul with this stack applied (and we already gate PRs on private gitea installation), therefore it got some real functional testing as well and is free of the most obvious crashes.
I tried to keep implementation as close as possible to existing GitHub/GitLab/Pagure drivers, but surely due to the differences on server side (especially lack of web hooks documentation and need to reverse engineer the code and use trial/error approach) there are some differences: - it is not possible to have labeled/unlabeled triggers, instead only label_changed (as the webhook reports) due to absence of the label change information - need to explicitly fetch branch definition on every event to be able to evaluate merge-ability (similar to Github it is required to re-calculate requirements on Zuul side) - absence of review dismissal event as such - different permission model
Otherwise it looks and behaves very similar.
Thanks and regards, Artem
Friendly reminder (not all current zuul jobs seem stable enough therefore rebasing big stack is a real mess with a lot of rechecks).
Thanks, Artem On Mon, Jul 25, 2022 at 6:49 PM Artem Goncharov artem.goncharov@gmail.com wrote:
Hi all,
Under https://review.opendev.org/q/topic:gitea_driver you can find stack of changes for implementing Gitea driver in Zuul. The work is not finished and not all features (from my pov) are implemented, but it already becomes expensive to manage long stack needing to rebase everything due to other parallel interface changes to Zuul. Therefore I would kindly ask Zuul cores to have a look and start giving first core reviews (there are non core reviews slowly coming).
ReleaseNote is supposed to be added once functionality is generally completed and verified. Amount of CRD tests is also to be heavily increased.
We are currently already running productive Zuul with this stack applied (and we already gate PRs on private gitea installation), therefore it got some real functional testing as well and is free of the most obvious crashes.
I tried to keep implementation as close as possible to existing GitHub/GitLab/Pagure drivers, but surely due to the differences on server side (especially lack of web hooks documentation and need to reverse engineer the code and use trial/error approach) there are some differences:
- it is not possible to have labeled/unlabeled triggers, instead only
label_changed (as the webhook reports) due to absence of the label change information
- need to explicitly fetch branch definition on every event to be able to
evaluate merge-ability (similar to Github it is required to re-calculate requirements on Zuul side)
- absence of review dismissal event as such
- different permission model
Otherwise it looks and behaves very similar.
Thanks and regards, Artem
On 9/23/22 03:15, Artem Goncharov wrote:
Friendly reminder (not all current zuul jobs seem stable enough therefore rebasing big stack is a real mess with a lot of rechecks).
Hi Artem,
Are you planning on using this in serious production? Or is this something you're doing out of general interest?
I ask because it seems like the Gitea API may be lacking in some areas, and I'm not sure it's ready (or Zuul is ready for it). I'm a bit concerned about the maintenance burden for this driver.
As for the job stability -- we would welcome any changes which make the tests more stable. That's a great way for folks to contribute to the health of the community.
And finally, I'm not sure the patch series needs to be quite so long. I have seen messages indicating that patches have been added to retain reviews. Please make things simple for reviewers by updating changes to address comments! It's much easier for a reviewer to re-apply a vote when they see a comment has been fixed rather than chase down the fix in a different change.
Implementing a new driver doesn't need to take a lot of changes.
-Jim
Hi Jim,
Thanks for comments.
To answer your question - yes, we run it on our side as part of mission critical infrastructure right now. So far things are going well. As I wrote initially - Gitea api is bit weird, but honestly speaking GitHub and Gitlab are also weird in different aspects, not a single one of them is designed 100% like you would expect from a good API. But also we personally are much more satisfied with it compared to both GitHub and Gitlab that are used in the same installation.
Now regarding patch series, I can press all of the changes into 2-3 changes which are going to be big. That will surely reduce the burden of rebasing, but not necessarily make it easier to review. At the moment it is built as this big series exactly because I wanted to keep individual patches considerably small and focusing on single feature (i.e. adding requirements or merge reporting). Do you have any suggestions whether to compress the changes and how granular? I can surely address reviews in the same change, I just did it this way to avoid rebasing big stack because of nits (and to keep reviews visible to signal further in the community those are not unreviewed at all). I fear having less, but bigger changes will not really help getting reviews, but reach a completely opposite goal.
Test stability: I would love to help, but already now I need to take care about so many things (especially in OpenStack) that I can't afford looking also to that topic, sorry.
Thanks, Artem ---- typed from mobile, auto-correct typos assumed ----
On Tue, Sep 27, 2022, 01:25 James E. Blair jim@acmegating.com wrote:
On 9/23/22 03:15, Artem Goncharov wrote:
Friendly reminder (not all current zuul jobs seem stable enough therefore rebasing big stack is a real mess with a lot of rechecks).
Hi Artem,
Are you planning on using this in serious production? Or is this something you're doing out of general interest?
I ask because it seems like the Gitea API may be lacking in some areas, and I'm not sure it's ready (or Zuul is ready for it). I'm a bit concerned about the maintenance burden for this driver.
As for the job stability -- we would welcome any changes which make the tests more stable. That's a great way for folks to contribute to the health of the community.
And finally, I'm not sure the patch series needs to be quite so long. I have seen messages indicating that patches have been added to retain reviews. Please make things simple for reviewers by updating changes to address comments! It's much easier for a reviewer to re-apply a vote when they see a comment has been fixed rather than chase down the fix in a different change.
Implementing a new driver doesn't need to take a lot of changes.
-Jim
participants (2)
-
Artem Goncharov
-
James E. Blair