NOTE: The docker setup is still WIP, production deployment is
discouraged until you see the container image uploaded to the project's Package
Registry on Codeberg
* I tested only `docker build`, next step is to make sure Vervis runs
properly (committing already because just getting it to build was a
long process)
* docker-compose.yml is coming next, as well as uploading the image to
Codeberg container registry
- I upgraded the actor system (Control.Concurrent.Actor) to support
typed per-actor methods with type-level names, parameter lists and
return values
- For extensible sum types, I decided to use the 'vary' package, while
extensible product still uses 'HList' (other options are to get both
from 'extensible' (Sum, Prod) or from 'vinyl' (Rec, CoRed))
- Since 'vary' is new, it uses GHC2021 and thus requires GHC 9
- So I decided to make the leap into upgrading to an LTS with GHC 9
- Vervis was at LTS 18, at first I tried 19 and 20 but there were
dependency version problems, in particular I couldn't solve them for
the 'darcs' package even when I switched to latest LTS which is 22
- So I decided it's time to do the long-waiting task of switching to
calling-darcs-process instead of using darcs as a library
All of this together creates a huge commit, but 3 big things are now
solved :)
I added a new activity type, Patch. There's already a ForgeFed type with
the same name, used for representing patches of course. Perhaps the
duplication will work, since these types are used in different
situations. I'd happily change to Edit, but Patch may become the
standard name in Fediverse software. So let's go with that.
- UI for creating a Factory
- UI for specifying a Factory when creating resource actors
- Old way of creation doesn't work anymore, except for Factory itself
- UI indicates whether you're an admin user
- Settings allow to choose "resident" factories, i.e. ones automatically
offered to every newly verified user
Caveats:
- Factories are all-in-one, no mechanism yet for choosing actor types
- No UI/logic for auto-offering a Factory to all users of a different
instance, and signaling other instances about newly verified local
users
- No factories inserted to DB yet
- Admin user list specified in settings
- Admins can create a Factory via C2S
- Creating other actors via C2S the old way still works as well
- Factory S2S handler implementation still blank
Until now, `Vervis.Ssh` was freely running git/darcs commands,
regardless of what the `Repo` actor is doing at the same time. It means
that in the `Repo` actor implementation, every repo manipulation must
take into account the possibility for a simultaneous push.
This commit gives more control, clarity and safety to the `Repo` actor.
Since moving the push logic itself to the `Repo` actor would be
cumbersome and complicated, the push logic remains in `Vervis.Ssh`, but
some thingss happen differently:
1. Before running the git/darcs command that handles the push, it waits
for the `Repo` actor to be available (as if pushing is one of the
`Repo` actor's methods)
2. In the method handler, the `Repo` actor waits for `Vervis.Ssh` to say
that the push handler is done
3. When the git/darcs command returns, `Vervis.Ssh` sends the
notification to release the `Repo` actor from the waiting
So, from now on, `Repo` and `Loom` code, in particular code that handles PRs,
can be sure no simultaneous pushing will happen.
The major changes:
- No more hit and hit-* packages
- No more diagram and SVG font stuff
- Dependency on darcs is not yet removed
- No more persistent-graph i.e. recursive SQL queries
- Some hit-network stuff still in use, now part of Vervis itself
- Git operations use the git command-line program, a convenient API is provided
in Data.Git.Local
- No more patch parsing and no diff view, patches are treated as a piece of
text and displayed as-is (although I could add syntax-highlighting as a nice
touch for the HTML view)
