This patch makes Vervis temporarily unusable, because all actors' inbox POST
handlers use the new system, but the actual federation handler code hasn't been
ported. The next patches will port all the S2S activities supported so far, as
well as C2S.
Here's how it works:
- When Vervis starts, it writes a config file and it writes post-receive hooks
into all the repos it manages
- When a git push is accepted, git runs the post-receive hook, which is a
trivial shell script that executes the actual Haskell program implementing
the hook logic
- The Haskell hook program generates a Push JSON object and HTTP POSTs it to
Vervis running on localhost
- Vervis currently responds with an error, the next step is to implement the
actual publishing of ForgeFed Push activities
My parser doesn't support default=, and I think it's safe to assume nobody is
running an instance whose DB schema version is one of those first 5 where
default= exists, so I'm remvoing it from the original 2016 model file. The
unset-default migrations remain, and I checked in `psql` that PostgreSQL
accepts the operation on columns that don't have a default value. If it turns
out to be a problem, I can replace those migrations with no-op ones.
The actor key will be used for all actors on the server. It's held in a `TVar`
so that it can always be safely updated and safely retrieved (technically there
is a single writer so IORef and MVar could work, but they require extra care
while TVar is by design suited for this sort of thing).
CSRF token check doesn't find the token in the login POST, so logins fail. For
some reason, yesod-auth-account intentionally avoided putting the token in the
login form. I updated the yesod-auth-account code to include the token. This
patch simply choose the new revision with the fix, so that logins work again.
Until now the list of DB migration actions was incomplete, containing only
changes made since I added the migration system itself. It now contains the
2016-08-04 model, and then every change made since then.
IMPORTANT: The 2016-08-04 instance doesn't have a schema version entity at all,
so it is assigned version 0, while the actual version of its schema is 1. I'm
going to patch persistent-migration to allow it to be 1, making the migration
path smooth.
