Zuul CI support #4251

New Issue

GiteaMirror · 2025-11-02T05:43:55-06:00

GiteaMirror commented

2025-11-02 05:43:55 -06:00

Originally created by @lunny on GitHub (Nov 6, 2019).

https://opendev.org/zuul/zuul

Originally created by @lunny on GitHub (Nov 6, 2019). https://opendev.org/zuul/zuul

GiteaMirror added the type/proposal label 2025-11-02 05:43:55 -06:00

GiteaMirror closed this issue

2025-11-02 05:43:55 -06:00

GiteaMirror commented

2025-11-02 05:43:56 -06:00

@rossmeier commented on GitHub (May 6, 2020):

I started looking at it. The pull-request API of Gitea and GitHub are very similar, so there should be little work there. The other APIs need some work adapting them, I would build on giteapy. At the moment, it doesn't look like any Gitea changes are required.
If anyone else has already started here or is willing to join my effort, I'd be glad to coordinate it.
CC @ChriFo @tumbl3w33d @blueworrybear @kazmardev @Snapstromegon

@rossmeier commented on GitHub (May 6, 2020): I started looking at it. The pull-request API of Gitea and GitHub are very similar, so there should be little work there. The other APIs need some work adapting them, I would build on [giteapy](https://github.com/dblueai/giteapy). At the moment, it doesn't look like any Gitea changes are required. If anyone else has already started here or is willing to join my effort, I'd be glad to coordinate it. CC @ChriFo @tumbl3w33d @blueworrybear @kazmardev @Snapstromegon

GiteaMirror commented

2025-11-02 05:43:56 -06:00

@tumbl3w33d commented on GitHub (May 6, 2020):

I've talked to corvus (one of the zuul maintainers and current project lead) about it and he was very interested in getting a gitea driver into zuul. From my understanding there shouldn't be anything needed on gitea side, but we will see when implementing.

An excerpt of my talk on #zuul (freenode IRC)

<corvus> tumble: oh you're using gitea, nice :)
<corvus> tumble: we'd love a gitea driver; and i bet you could trick some of us into collaborating on it :)
<tumble> yeah and I hoped since opendev is gitea-based as well, I'd be lucky to find a driver for it, but unfortunately not the case :D
<tumble> I looked at the github and gitlab drivers and while the github one looks quite huge, the gitlab one ain't so bad so I at least consider it doable
<corvus> it's also super easy for us to test too, which is nice
<corvus> tumble: also check out the pagure driver
<tumble> will do, tbh I didn't hear of pagure before, should look at it anyway. You never stop learning :D
<corvus> tumble: it might be a good combination of "simpler than github, but more finished than bitbucket"
<corvus> tumble: we'll want to make sure we have good webhook support in the gitea driver, and the bitbucket one is largely based on polling which won't scale as well
<tumble> corvus, yeah good point. I'm used to on-commit hooks from our current jenkins workflow and I don't wanna go back to polling
<corvus> tumble: if you have some time for this, i can probably help out starting later this week
<corvus> probably the easiest way to start would be to set up a local zuul dev environment (one where you can easily update and interactively run the zuul-scheduler process) with a gitea, then start on the driver.  the first thing the driver will want to do is to query gitea for a list of branches for each of the projects specified in the config.  that's a good checkpoint.  :)
<corvus> then it's implementing webhooks to respond to events, some more queries, etc.
<corvus> once that's all working with a real gitea, we'll add some unit tests that fake out part of it so we can regression test drivers without running the whole thing
<tumble> corvus, I'll be hanging out here from now (if I don't forget to launch my hexchat) and sure, let's see what we can do. Friday is a bank holiday here and I'll probably find some time to look into this over the weekend :)
<corvus> tumble: sounds great :)

I'd be willing to support the efforts. I can write code and test stuff with my own gitea + zuul setup. I lack quite a bit of zuul experience though, but the guys behind it seem very open and helpful.

@tumbl3w33d commented on GitHub (May 6, 2020): I've talked to corvus (one of the [zuul maintainers](https://zuul-ci.org/docs/zuul/reference/governance.html) and current project lead) about it and he was very interested in getting a gitea driver into zuul. From my understanding there shouldn't be anything needed on gitea side, but we will see when implementing. An excerpt of my talk on #zuul (freenode IRC) ``` <corvus> tumble: oh you're using gitea, nice :) <corvus> tumble: we'd love a gitea driver; and i bet you could trick some of us into collaborating on it :) <tumble> yeah and I hoped since opendev is gitea-based as well, I'd be lucky to find a driver for it, but unfortunately not the case :D <tumble> I looked at the github and gitlab drivers and while the github one looks quite huge, the gitlab one ain't so bad so I at least consider it doable <corvus> it's also super easy for us to test too, which is nice <corvus> tumble: also check out the pagure driver <tumble> will do, tbh I didn't hear of pagure before, should look at it anyway. You never stop learning :D <corvus> tumble: it might be a good combination of "simpler than github, but more finished than bitbucket" <corvus> tumble: we'll want to make sure we have good webhook support in the gitea driver, and the bitbucket one is largely based on polling which won't scale as well <tumble> corvus, yeah good point. I'm used to on-commit hooks from our current jenkins workflow and I don't wanna go back to polling <corvus> tumble: if you have some time for this, i can probably help out starting later this week <corvus> probably the easiest way to start would be to set up a local zuul dev environment (one where you can easily update and interactively run the zuul-scheduler process) with a gitea, then start on the driver. the first thing the driver will want to do is to query gitea for a list of branches for each of the projects specified in the config. that's a good checkpoint. :) <corvus> then it's implementing webhooks to respond to events, some more queries, etc. <corvus> once that's all working with a real gitea, we'll add some unit tests that fake out part of it so we can regression test drivers without running the whole thing <tumble> corvus, I'll be hanging out here from now (if I don't forget to launch my hexchat) and sure, let's see what we can do. Friday is a bank holiday here and I'll probably find some time to look into this over the weekend :) <corvus> tumble: sounds great :) ``` I'd be willing to support the efforts. I can write code and test stuff with my own gitea + zuul setup. I lack quite a bit of zuul experience though, but the guys behind it seem very open and helpful.

GiteaMirror commented

2025-11-02 05:43:56 -06:00

@jcgruenhage commented on GitHub (Aug 7, 2022):

Has there been any progress on this?

@jcgruenhage commented on GitHub (Aug 7, 2022): Has there been any progress on this?

GiteaMirror commented

2025-11-02 05:43:56 -06:00

@delvh commented on GitHub (Apr 29, 2023):

If I understand this issue correctly, I don't think it's necessary anymore as Gitea Actions have been merged.

@delvh commented on GitHub (Apr 29, 2023): If I understand this issue correctly, I don't think it's necessary anymore as Gitea Actions have been merged.

GiteaMirror commented

2025-11-02 05:43:57 -06:00

@techknowlogick commented on GitHub (Apr 29, 2023):

If I understand this issue correctly, I don't think it's necessary anymore as Gitea Actions have been merged.

Even with Gitea Actions, we still have a mission of supporting third party CIs, and a part of Actions is to have that open protocol to allow third parties to use the same close integration that is available to the runners. We are also long time backers of Woodpecker.

I agree that this ticket should be closed, but for the reason that Zuul would need a new driver, and it's not something that we can add in Gitea.

@techknowlogick commented on GitHub (Apr 29, 2023): > If I understand this issue correctly, I don't think it's necessary anymore as Gitea Actions have been merged. Even with Gitea Actions, we still have a mission of supporting third party CIs, and a part of Actions is to have that open protocol to allow third parties to use the same close integration that is available to the runners. We are also long time backers of Woodpecker. I agree that this ticket should be closed, but for the reason that Zuul would need a new driver, and it's not something that we can add in Gitea.

GiteaMirror commented

2025-11-02 05:43:57 -06:00

@6543 commented on GitHub (Apr 30, 2023):

if zuul-ci devs read it, would be nice if they could also contrib to https://github.com/woodpecker-ci/woodpecker/issues/1385 or at least have a watch on it ;)

@6543 commented on GitHub (Apr 30, 2023): if zuul-ci devs read it, would be nice if they could also contrib to https://github.com/woodpecker-ci/woodpecker/issues/1385 or at least have a watch on it ;)

GiteaMirror commented

2025-11-02 05:43:57 -06:00

@lunny commented on GitHub (Apr 30, 2023):

I support closing this one. Not because I think actions could do anything, we in fact should support third-party CI/CD like before and even better. But looks like most work is in zuul or a plugin but not Gitea side.

@lunny commented on GitHub (Apr 30, 2023): I support closing this one. Not because I think actions could do anything, we in fact should support third-party CI/CD like before and even better. But looks like most work is in zuul or a plugin but not Gitea side.

GiteaMirror referenced this issue

2025-11-02 12:32:04 -06:00

[PR #4251] [MERGED] Fix #4060 by showing second line of commit #17301

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#4251