Radicle Developer Tooling // Jan-Mar 2024
Over time, our team has taken on work on different parts of the Radicle ecosystem, helping build more tooling around the decentralized code collaboration solution.
This Radworks Grant application requests funding to continue ongoing work in the following areas, to cover the period between 15 Jan - 31 March 2024:
- CI/CD, IDE and Zulip integrations
- Migration Tooling
- Planning Boards Tool
For each of these areas, we outline the specific work items we will focus on during this time. For each project, we outline:
a. the high-level focus areas,
b. how long we will invest working on these areas.
In the background, we are also trying to figure out a longer-term plan to better integrate our team into a more permanent role within the Radworks ecosystem, but that is beyond the scope of this proposal. Watch out for other discussions in this forum on that topic.
1. Integrations with Continuous Integration / Continuous Delivery (CI/CD) Tools
Full-time equivalent (FTE) Capacity: 89.5 FTE days
Ahead of a “1.0” launch for our decentralized code collaboration solution, it is important to be able to show integrations with existing CI/CD systems, so that users that would onboard to Radicle don’t have to worry about also migrating their pipelines. By integrating with their existing tools, we will have one less hurdle for adoption.
GitHub Actions
The GitHub Actions integration is already functional, at the proof-of-concept level.
Our focus areas here include:
- Working examples: Enable this integration on at least 3 projects (jetbrains plugin, vs code extension, github adapter), to offer examples that new users who want to migrate from GitHub → Radicle can follow to set up this integration on their own projects.
- Better reporting: Enrich the GitHub Actions adapter with more details for each workflow, enabling detailed results in the comment reported back to the patch about which specific workflow failed (as opposed to a simple “success / failure” comment)
Jenkins
As Jenkins is perhaps the most widely adopted self-hosted CI server, we should implement a first version of the plugin that allows integration with Radicle.
On the Radicle side, no extra implementation will be required: we will use the existing outgoing webhooks.
Our focus areas here include:
- Implement a new Jenkins plugin that will:
- process Radicle webhooks and trigger Jenkins jobs
- provide a pipeline step that allows pipelines to send results back to patches (as comments, for the time being)
- Publish documentation about how to deploy a Jenkins instance, install the Radicle Plugin and configure it with the Radicle Broker, Webhooks Adapter and HTTP API.
- Working example: set up the CI pipeline of at least one project on Jenkins, on our public node.
Outgoing Webhooks
We are currently in a position to send basic outgoing HTTP webhooks to 3rd party systems. In this second iteration of work on the webhooks, we want to improve and extend the existing functionality.
Our focus areas include:
- persist webhook results: One missing feature with the existing outgoing webhooks is that the result of the outgoing HTTP request isn’t currently persisted, so there is no detailed record of which webhooks have been successfully sent to the 3rd party system we are integrating with. We want to persist all webhook requests, so that it is also possible to retry failed requests, on par with what other outgoing webhook integrations offer in other Forges.
- improve reporting: report detailed status per webhook to broker, as opposed to the current “all or nothing” approach we have today.
- improve documentation: provide further docs & tooling on enabling webhooks, making them easier to setup, less of a chore, etc.
- extend webhook events: add some new event types that are important for Radicle users.
- “comment”: many users want to know when a new comment has been left on their patch. This is also used in integrations with 3rd party systems, to support “ChatOps” - style interaction with patches, such as for example
test/re-test/approvecomments that can trigger CI pipelines. - “review”: a patch review (and whether it has been approved or not) is one of the most important events to be notified about as a contributor.
- “comment”: many users want to know when a new comment has been left on their patch. This is also used in integrations with 3rd party systems, to support “ChatOps” - style interaction with patches, such as for example
Woodpecker
The Radicle Forge integration for Woodpecker exists as a proof-of-concept and has been shown to work.
In order to make it generally available however, it now needs to undergo a small rewrite as a “Woodpecker addon”. The addon system was added specifically to support additional Forges in Woodpecker, especially non-established ones like Radicle. As such, we need to port our current implementation to a separate addon, so that any Woodpecker user can choose to deploy it.
With that in mind, our focus areas here include:
- Port current implementation to “Woodpecker Addon”
- Complete documentation and create a guide explaining how to enable Woodpecker CI on Radicle projects.
- Provide at least one example of a project that has a CI pipeline running on Woodpecker.
Concourse
The integration with Concourse CI was implemented a while ago, on the previous incarnation of the Radicle Broker. It does not currently work with the new Broker - Adapter architecture.
Our focus areas for Concourse include:
- Migrate the existing business logic to a separate adapter, so that it is available for users who want to use Concourse CI and also serves as an example of how to implement similar integrations with other CI systems that offer an API.
- provide documentation about how to deploy Concourse with Radicle and
- publish at least one example project that has a pipeline on Concourse CI.
Explore Zulip Integration
With several teams (Heartwood, radicle-interface and our own) now relying on Zulip to fill in the missing functionality around working with Patches and Issues, we want to explore if we can use the Radicle Broker + Outgoing Webhooks Adapter to integrate some notifications in Zulip.
This integration can result in real-time notifications, updates, and alerts within the Zulip interface, ensuring that team members are promptly informed about relevant activities, discussions, and changes related to their projects. This aims to streamline the workflow associated with Radicle Patches and Issues, providing a centralized communication hub for all teams involved.
It should be noted, that we are not yet sure how much is possible here and what level of notifications we can have right now. We will spend some time exploring and hopefully be able to provide some kind of alpha version of a Radicle Zulip Integration.
2. Radicle in Integrated Development Environment (IDE) Tools
Full-time equivalent (FTE) Capacity: 67.75 FTE days
Jetbrains IDE Plugin
IntelliJ and other Jetbrains IDE users are the first Radicle users that can already properly review Patches by leaving general and inline comments (allowing in-place discussions about specific code changes to come to life) and creating/merging Patches directly from the IDE.
In our next release, we will focus on:
- the last missing piece of the puzzle: Revision Reviews. This will be the only new feature.
- The rest of the work will cover bugfixes, User eXperience (UX) and Development eXperience (DX) improvements and general “quality of life” improvements, while also ensuring the plugin stays up-to-date with the breaking changes in Heartwood and the
radicle-httpd.
In more detail, here is the current plan (which is very likely to change, as work progresses) for the scope of the v0.9 Milestone.
VS Code Extension
In a nutshell, the plan for the upcoming v0.5 version is to support code reviews in VS Code and to complete the Patch workflow, by allowing users to both create, but also to merge patches. A lot of this work was targeted for v0.4, but has been pushed to v0.5 due to the need for important additional infrastructure groundwork in v0.4 - i.e. Webviews and refactoring the app’s state management into a reactive global store.
More specifically, you can see the currently planned functionality (which may change over time) on the v0.5 Milestone.
3. Migration Tooling
Full-time equivalent (FTE) Capacity: 14 FTE days
Migrating an entire project from another forge (GitHub, GitLab, Gitea) introduces a significant hurdle. By creating migration tools, we can lower the overhead and make it that much easier for teams to migrate their projects. Without this, the task is daunting and may be too high a hurdle to convince teams to switch tooling to Radicle.
Our team has already delivered tooling for Migrating GitHub Issues from GitHub → Radicle, as part of this Radworks Grant.
Our focus areas here include:
- Allow users to migrate GitHub Wikis → Radicle
- Allow users to migrate GitLab Issues → Radicle
- Allow users to migrate Gitea Issues → Radicle
- Extend the current implementation so that it can function as an always-on mirroring tool for GitHub Issues → Radicle. This will allow the tool to pick up new changes on GitHub issues and update the already created, corresponding Radicle issues, rather than creating new issues on every run.
4. Planning Boards Tool
Full-time equivalent (FTE) Capacity: 24.5 FTE days
One of the missing features that has been highlighted by every single team that is has moved their daily workflow to Radicle is some kind of board view of their backlog items, so the team can better plan their work and roadmap.
Based on stakeholder feedback on zulip, we have developed an early proof-of-concept, retroactively funded by a Radworks Grant.
In this Grant application, we would like to fund a little bit of further work in this area, so we can move beyond the proof-of-concept and ship a first alpha version of the application.
Our work areas here include:
- Align with Heartwood team on what route to follow for persisting the necessary information for the boards
- Align with the Web team on how to integrate the Planning Boards web app into the existing Web UI for radicle (
radicle-interface) - Take codebase from “proof-of-concept” to “alpha” quality status: a lot of corners had been cut as part of the first PoC phase, that we now need to come back to, as we move towards making this actually usable.
- Ship a hosted version of the planning boards in our own public node: this way there is no additional overhead on the Web team in terms of maintaining or operating this application.
- New features (as time will permit):
- filtering: to allow finding issues faster, or displaying only certain relevant features on the board (e.g. ones that have a specific label)
- improve overall look & feel, also taking into account some suggestions from the Web team (thanks Daniel!
) - editable issues: allow editing some issue fields directly from the UI.
Budget
- Total Duration: 11 calendar weeks (Jan 15 - Mar 31 2024)
- Full-Τime Εquivalent (FTE) Capacity: 195.75 FTE days
- Total Budget: 82 500 USDC + 35 000 RAD
- Recipient Wallet: 0x445717316388f1d1fb1730D3f6f9Bf59e0b03f4f
For the first time, we would like to request part of our payment in Radworks tokens (RAD), as both a testament of our belief in this project, and an indication of our long-term commitment to the Radworks community.
Note: The RAD amount has been estimated using the average price of the last 6 months (1.53 USD), based on historical data from coingecko, to account for volatily / instability.
Drips-Powered Payments
We would like to continue “drinking our own champagne” with Radworks product stack and would propose to use Drips (which has worked great so far!).
Legal Structure
- Registered Legal Entity: Cytech Ltd.
- Registered Address: Science & Technology Park of Crete, Heraklion, Greece
Team 
Team members
The team is comprised of 8 team members, all currently contributing to Radicle in a part-time capacity:
- Yorgos Saslis
- Ioannis Christodoulou
- Stelios Mavrommatakis
- Kostis Maninakis
- Michalis Zampetakis
- Zacharias Fragkiadakis
- Themistoklis Dakanalis
- Vaggelis Antoniadis
This is the same team that’s delivered the other Radworks Grant-funded work. See previous grants for more info.
CI Integration guides:
migrate GitHub Wikis → Radicle
use this tool as an always-on mirroring tool for GitHub and GitLab Issues → Radicle. The tool picks up new changes on GitHub/GitLab issues and updates the already created, corresponding Radicle issues, rather than creating new issues on every run.