halkyon-days/halkyon
Watch
1
0
Fork
You've already forked halkyon
 0
Code Issues Pull requests Projects Releases 37 Packages Wiki Activity Actions

feat(publish): releases in git (public tier, stage 2)

Browse source 
A person with an identity and a public profile publishes a studyset with
everything inside it as its next release (ADR 0005, rule 3): the server
reads their synced rows and writes them through the git command as a
commit on main and the annotated tag vN, in a bare repository of the
studyset's own, named by a random public id made at the first publish.

A release is a directory per studyset with a file per card, note, path,
step and PDF (its id, position, tag names and payload as synced, keys
sorted and indented) and the files the content names, without what is
only the author's (a card's report, a PDF's deadline). Publishing is
refused without a licence allowing passing it on in every studyset ("no
derivatives" allowed), with revisions to settle, with files not uploaded
yet, when nothing changed, or for a name that won't do; the name is
fixed from the first release, as is the person's handle.

In the app, Share in a studyset's action row opens the Publish sheet;
publishing syncs first, and settles by itself the revisions that merge
cleanly, listing only real conflicts. The server's image gets git, the
repositories a volume of their own, and the hourly backup a git bundle of
each.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MMm7usAo6q9ZZRoPkWjoxi
Signed-off-by: Tizian 「ティツィアーン」 <raisondetredev@pm.me>
This commit is contained in:
Tizian 「ティツィアーン」 2026-10-09 22:01:00 +02:00
commit f635b0816a
Signed by: raisondetredev
GPG key ID: 07F6FCF405488B64
1 changed files with 20287 additions and 77 deletions
Download patch file Download diff file Expand all files Collapse all files

29
deploy/backup.sh
View file

@ -4,8 +4,9 @@
# how it was set up and how to restore.
#
# Everything people keep is in the database, their files too (Serverpod's database
# cloud storage), so one dump covers the instance; the secrets in deploy/.env are kept
# in Proton Pass instead. restic stores the dump encrypted in a Hetzner Storage Box
# cloud storage), but for the releases of published studysets, which are git
# repositories in the server's volume: a dump and a bundle of each repository cover
# the instance; the secrets in deploy/.env are kept in Proton Pass instead. restic stores the dump encrypted in a Hetzner Storage Box
# and keeps 24 hourly, 7 daily, 4 weekly and 3 monthly snapshots (decided 2026-10-03).
# Hourly, because a restore loses what came after the backup, and for someone who
# started since, that is everything: their app no longer finds its session and starts
@ -44,7 +45,29 @@ dump="$HOME/backups/latest.dump"
)
mv "$dump.partial" "$dump"
restic backup --quiet "$dump"
# Each repository as a git bundle, after the dump: a release the dump lacks is never
# numbered again (the server numbers past the highest tag), while one the bundles
# lacked would be lost. A bundle is whole whenever it is made: git reads the refs, then
# packs what they reach. A repository being created this moment has nothing to bundle
# yet, and comes next hour.
releases="$HOME/backups/repositories.tar"
(
umask 077
docker compose exec -T server sh -c '
out=$(mktemp -d)
for repository in /app/repositories/*.git; do
[ -d "$repository" ] || continue
git -C "$repository" bundle create --quiet \
"$out/$(basename "$repository" .git).bundle" --all ||
echo "Not bundled: $repository" >&2
done
tar -C "$out" -cf - .
rm -rf "$out"
' >"$releases.partial"
)
mv "$releases.partial" "$releases"
restic backup --quiet "$dump" "$releases"
restic forget --quiet --keep-hourly 24 --keep-daily 7 --keep-weekly 4 --keep-monthly 3
# Once a day, in the run at 03:00: free the space of forgotten snapshots, and read the