We've had a short disucssion on IRC about maybe adding support to Gitano (a
git server) and ick for ActivityPub instead of having explicit triggers
configured in Gitano to trigger builds in ick. I thought I'd expand on that
a little bit.
The thing I'm grasping at is that currently, each git server instance needs
to notify each CI instance separetely, creating a fairly tight coupling.
Alternatively, each CI instance needs to poll each git server, which is
unworkable at scale.
So currently, if there are three users, one using github.com
, one using
, and one using the Debian gitlab instance (salsa), and each user
is developing their own software, then each user needs to configure their
own git server to notify their own CI server. So far, so good.
However, if each of the three also wants to build and deploy each other's
software, so that if user A makes a change, it gets put through CI by A's,
B', and C's CI, and then deployed to A's, B's, and C's production
and likewise for B's and C's software, then each of the three needs to add
a trigger hook on each of th three git repositories. That's three
repositories, three CI servers, and a total of nine trigger hooks.
That's still manageable, but there are problems. Not all git servers allow
random strangers to add trigger hooks on each repository. Also, three
repositories and three CI servers is small potatoes. Imagine having fifty
thousand repositories! Debian has about that many binary packages.
Also imagine that those fifty thousand repositories are used by a million
users. Not all of them by all users, but many repositories by each of the
million. Having millions of hooks does not scale. Having that much polling
also doesn't scale.
So here's the solution I'm thinkin of: instead of having the git server
notify each CI server, have the git server send a message to an ActivityPub
server, and have each CI server listen on such messages on their own
ActivityPub server. The AP servers federate (send messages to each other),
so each git server and each CI server only needs to post to and listen on
one AP server.
With this design, many-to-lots communication becomes feasible.
A makes a change, and pushes to their git server. The git server posts a
message to its own AP server, saying "this branch on this repo on this git
server has changed, new commit it CAFEBEEF." The AP server knows who's
"following" A's repository, and so the message flows out to the AP server
network to every AP server where a CI server is interested in that
repository. Each of those CI servers can then trigger a build and deploy of
I don't actually know much about ActivityPub yet. It's the protocol behind
the Mastodon system (https://joinmastodon.org/
), and it works fine for a
Twitter clone. I don't know yet if it would work for what I'm talking about
above, but I think so.
Of course, doing distributed CI at this scale might not be something that
anyone actually cares about. We'll see. But even at a small scale, I'd like
to break the necessity of the git server having to know about each CI
server that is interested in each of its repositories.
Also, this needs thinking for non-public repositories.