This is a good fit primarily if you want to run a Radicle node that only seeds repos you tell it to. If you want to write code which you publish on Radicle, you need the tool that signs all your work with your private key (of your Radicle identity) - i.e. the `rad` CLI - and running that in a container isn't very useful. (e.g. think about how you'd replace `rad clone`). Having said that, here's a container image I maintain, in case it helps: https://quay.io/repository/radicle_garden/radicle-node
In a nutshell, I summarise it like this: I see Open Source Software is a public good. As a public good, it doesn't belong in any proprietary platform, nor should orgs of any kind be in a position to gate keep it. We should rather host it on a public, peer-to-peer network that everyone can have access to.
yes, we currently have just the base building blocks (`rad follow` - allowlist / `rad block` - blocklist) for the fancier things to be built on. When you "seed" a repository, by default you seed it only with "followed" scope, which means you would only see issues and "Patches" (our term for PR/MR) from the repo maintainers + other peers you follow (i.e. in your allowlist).
it's a little of both: on the one hand we're working on CI integrations (through generic webhooks or CI-engine-specific adapters that basically implement the CI engine's API [1]), so you can keep on using your existing CI solution. On the other hand, yes, there is also work towards a new CI engine (Ambient
[2]), which aims to make it safe and secure to run CI on other people's code, which is important when working towards a distributed, community-ran, CI system. We should have more docs regarding the CI story up on radicle.dev in the next week or two.
1. yes, it's in the user guide [1]
2. Git LFS should work, yes. Care to try and report back ? ;) Open a new topic on the Zulip #Support channel [2] if you run into any issues.
The whole point we started using automation servers as an integration point was to avoid the "it works on my machine" drama. (Have watched at least 5 seasons of it - they were all painful!).
+1 on running the test harness locally though (where feasible) before triggering the CI server.
So, if I understand correctly, you’re not so much concerned about the p2p architecture, rather than the default seeding policy? (You’d prefer that to be selective rather than open by default? )
Probably not the "easiest", and it's not really production-ready yet, *but* it is the one open source solution for hosting open source software that will never be affected by the "Explores Sale" problem - the same way that BitTorrents have never had that problem: it is a fully decentralized, peer-to-peer network for hosting source code.
agreed. Jenkins has suffered from a lot of problems - plugin maintenance across version upgrades being key - but it has also overcome a lot of these problems. It gets criticism just for being... "old". But it is an automation server that is as battle-tested as they come!
Also, being old gives it a huge advantage: you can bet you won't need a major rewrite of your pipelines in a couple of years when e.g. GitLab sells, or Microsoft decides GH actions aren't so free (or fast) any more, etc.
I have to say "Datadog" isn't exactly as scary as "Microsoft" was, back when it bought GitHub.
Ok, they didn't kill the open source community which is what we feared at the time (because they found a way to make more money from it), but I'm still more skeptical of Microsoft essentially controlling the world's open source software than Datadog buying an open core company.
But with Microsoft now painting everything with its "AI" brush, aren't you, as open source maintainers, concerned about keeping the world's FOSS on a proprietary platform?
> The risk only comes in if gitlabknockoff was AWS, Azure, or GCP, which we're still learning what to do about.
Exactly! It really makes me wonder how GitLab thinks Datadog can help them defend against this risk. Then again, they're not open source - just open core.
- finding what the domain name is ?
- resolving the DNS to an IP address ?
Radicle solves both problems in theory, but more the latter than the former right now:
- there is some basic functionality to search for projects hosted on Radicle, to find the right repo id (I expect this area will see a lot more activity and improvements in the near future),
- given a repo id, actually getting the code onto your laptop. This is where the p2p network comes in, so that the person hosting it doesn't always need to keep their computer/router/tv box on, etc.
In addition, in order to migrate your GitHub issues to Radicle (which the above doesn't cover), there's this command-line tool [1] that should get you most - if not all - of the way there.
Migrating GitHub Pull Requests (PRs) to Radicle Patches is somewhat more involved, but that should still be possible (even if it involves some loss of information along the way, due to potential schema mismatches) ...
That is the default port for `radicle-httpd`: an HTTP API that would allow you to authenticate (using your public/private key pair, that is stored on your machine), so that you can perform actions on the web-based interface as a specific user, through your local radicle node.