Proposal for adding Radicle forge

[mzampetakis]

Clear and concise description of the problem

Radicle is a sovereign peer-to-peer network for code collaboration, built on top of Git. Radicle enables users to run their own nodes, ensuring censorship-resistant code collaboration and fostering a resilient network without reliance on third-parties. It is under heavy development and currently in alpha version. Apart from the development of the protocol itself it is pretty crucial for radicle community to integrate it with popular and well-established tooling around it so that it will offer developers an easier adaptation process and a complete solution. Having this integration in place will allow even more developers to use woodpecker-ci within their radicle repos. Apart from this, developers that have already setup their CI pipelines in woodpecker will be able to transfer their repos to Radicle and keep their jobs running with minimum effort! With this integration Woodpecker will also become one of the first CI systems to be integrated with Radicle and can position itself as a solution that supports user sovereignty and isn't just compatible with centralized solutions.

I would very much like to work on this integration / implementation and I was wondering if the maintainers will be open in accepting a PR and perhaps providing some help along the way ?

Suggested solution

I will implement a new forge for Radicle as the existing ones alongside all the official documentation and tutorials required to support it.
As radicle has a different philosophy compared to the already implemented forges there are some limitations. While some issue might arise during the development of this integration there will be significant support form the radicle team to overcome them when feasible. Here are some of them that I have already identified:

1. Radicle does not support oAuth. Having the nodes properly set up, repos will be available to each connected node, so there is no necessity for authentication except when "enabling" a repo (check Version the drone-ui dependency #2). Authentication can be achieved through auth keys (public/private).
2. Enabling a repo at woodpecker is the process where the hooks at the specific repo are registered. This action is not (still) available through an API call at the Radicle side. This action is currently supported by adding a specific file within the radicle node so it can be accomplished as a manual step.

Alternative

No response

Additional context

No response

Validations

• Checked that the feature isn't part of the next version already [https://woodpecker-ci.org/faq#which-version-of-woodpecker-should-i-use]
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[anbraten]

Radicle seems quite interesting. We are open to adding support for it, however if larger adjustments to the fundamentals of Woodpecker will be required we need to check again if its worth the effort and maintenance based on the community interest.

As you mentioned correctly already there are some main interfaces of Woodpecker and the forges:

• oAuth for access
• webhooks to trigger pipelines after someone pushed / tagged / ... code
• the clone plugin to get the repo data to execute pipelines on
• some api calls like listing all branches / PRs, getting a file which could be ignored for the beginning

Some questions I currently don't understand from how radicle works / your proposal:

• radicle uses multiple nodes all being fully indepenent, however woodpecker needs to talk to some node at the end to call the api, clone the repo etc, right? Couldn't there also be an oAuth endpoint on a local node doing local oAuth (like mastodon is doing it for example)? To which api is the radicle UI talking to and how can users authenticate in the UI?
• Webhooks will be triggered by a specific node, but for now you need to configure it by committing sth like a git-hook to a node?
• How would you clone a repo for the pipeline? Looks like there is a special git wrapper is used. So you would need a special clone plugin as well, I guess.

[qwerty287]

Not yet, woodpecker does not even support it yet, it's just an approach. It's on my todo list after we released 2.0 though :)

[qwerty287]

I actually just had nothing else to do, so I started working on in and I got a working prototype already, so I'll see when I can finish it and open a PR.

[mzampetakis]

Thank you all for your feedback. It's really valuable! 🙌🏻
@gsaslis made a pretty good abstraction on how radicle works and how we have designed its integration with woodpecker.

I do understand the bottlenecks about oAuth and webhook enabling process, as both of them are part of the backbone of woodpecker's forges integrations.

Supporting the Radicle forge using Plugins seems an appealing approach and it might be a good fit for this case. My only concern is how - but most importantly when - woodpecker plans to support them. Thankfully, @qwerty287 started working on this 🎉 , so, please let me know if I can provide any kind of assistance on that - I would love to!

As for the implemented plugins (such as this one we are curenlty discussing or any other that might appear in the near future): are there any plans for them to be integrated officially with woodpecker. I mean, could they be offered through a centralised point as woodpecker does with plugins right now so user's could be informed officially by their existence and support? This is definitely something that could come later on but having the maintainers' feedback is pretty valuable.

Maybe these types of plugins have to come with a different naming comparing to the existing ones that are used for enriching pipelines' tasks. 🤔

[qwerty287]

Maybe these types of plugins have to come with a different naming comparing to the existing ones that are used for enriching pipelines' tasks. 🤔

Yeah I called them "addons" in my prototype.

And yes, when we implement/add this, I'd create an index similar to the plugin index to find these addons.

About the time plan: Probably it will be available in the next minor release 2.1.0, but I can't give you an exact time - I need to finish it first and open a PR then.

[mzampetakis]

These are great! I did not expect an exact time by any means 😉
Thanks!

[6543]

I propose that the ideas are almost ready ...

So why not draft a pull and figure out the painpoints, so we can address them on both sides while they apeare?

[mzampetakis]

For the records here is the PR which is now merged: #2751

[mzampetakis]

I have faced an issue where the type of the pull request RemoteForgeID is strictly expected to be an integer (int64) instead of a more generic string type that it is used for other RemoteForgeIDs. At radicle's side a Pull request ID (called patch) it is of string type.
I have describe this case in another issue: #2746 but it's related to this implementation.

I would like to have your feedback on this as it seems that it does not follow the other RemoteForgeIDs' types which results to a non-uniform approach for this type.

[mzampetakis]

Issue addressed by #2823

[mzampetakis]

Now that there is the addon support we can move forward and implement the Radicle forge. 🎉
Thanks for getting this support done! ❤️

Is there any designated repo for adding such implementations, or there will be some official listing for 3rd party implementation?

[mzampetakis]

I have already started the implementation, but still haven't migrated to an addon type (I am integrating it directly to woodpecker repo).

What do you mean? If adding it to the main repo it must be documented there otherwise in a separate add-on registry.

This is what I mean! The other solution is to be implemented and maintained by add-on authors and listed in some central index as there is one for plugins.

[qwerty287]

The other solution is to be implemented and maintained by add-on authors and listed in some central index as there is one for plugins.

That's the plan from my side. It just needs to be done ;)

[mzampetakis]

Please let me know if there is any repo that I could contribute to, in order to assist on the creation of the aforementioned central index page!

[6543]

I would start with adding a cookbook ... how to do radice + woodpecker.

that's a more block like aproach and as it is still fresh new forge plugin this should fit best.

if it did run & is deployed without issues for some time ... we can add it to the forges overview.

as for go-plugins that can come seperated ... for now we could just use the awesome page.

we just have to make sure go-plugins are not plugins ... and if not pointed out clearly it will be a mess for users.
so I would propose to call go-plugins addons or so

[qwerty287]

as for go-plugins that can come seperated ... for now we could just use the awesome page.

I also think the awesome page is fine for now, later I'd add a separate index similar to plugins.

so I would propose to call go-plugins addons or so

That's how they called already :)

[mzampetakis]

We can close this discussion as woodpecker now supports addons that allows us to develop an external forge addon for radicle.

Thank you all!