Skip to content

releases and rebases

the editor is a fork of hedgedoc 1.x. two files in this repo are its whole source of truth:

  • editor/UPSTREAM: the upstream release tag the fork sits on.
  • editor/critic.bundle: a git bundle of every fork commit on top of that tag.

an image build clones upstream at UPSTREAM, fetches the bundle, checks out critic, and asserts that the tag really is the bundle's base. nothing else is needed, which is why a clean clone can build the editor and why the pair satisfies AGPL's corresponding-source obligation.

the rebase is a maintenance step; builds never run it.

bumping upstream

./editor/rebase.sh              # newest 1.x tag
./editor/rebase.sh 1.11.1       # or a specific one

it keeps a checkout in editor/.work (gitignored, several hundred MB), rebases critic onto the target, rebuilds package.json as upstream's dependencies merged with the fork's, regenerates yarn.lock, commits both onto critic as a Specdoc-Lock: commit, and refreshes critic.bundle and UPSTREAM.

that lock commit matters: the conflict resolution keeps the fork's side of package.json, so without it the branch carries a manifest that is missing whatever upstream added since the fork. the next rebase drops the old lock commit before replaying, so they do not stack.

  • 1.x only: the tag scan skips 2.x on purpose, since it is a different architecture and rebasing onto it would produce garbage without saying so.
  • conflicts outside package.json, yarn.lock and .github/workflows stop the script. resolve them by hand in editor/.work on branch critic, then re-run. every run saves a backup/critic-<timestamp> ref first.
  • a fresh checkout is seeded from critic.bundle, never from the upstream fork it started as. --bootstrap-from-fork exists for the day you want the original fork instead, and it discards the local commits.

then, in this repo:

git add editor/UPSTREAM editor/critic.bundle
hack/build-editor.sh            # rebuild both images against the new base

commit the bundle in the same change as anything else that moved. the fork's own patch ledger lives in FORK.md on the critic branch, not here: read it with git -C editor/.work show critic:FORK.md.

shipping

pushing to master is the release. a cronjob in the cluster compares the remote head to the last build every five minutes, starts a build when they differ, and an image trigger rolls the deployment to the new digest. no laptop involved, and the build objects live in the infra repo.

the exception is an upstream bump: the source snapshot (editor-src) is not polled, because it changes only when UPSTREAM or critic.bundle change and costs a full clone plus a full install. after committing those, run oc start-build editor-src -n hedgedoc; the editor image follows on its own. an editor build against a stale snapshot fails rather than shipping the wrong source.

roll back by retagging the previous image; a git revert would rebuild but not undo the schema, since the board migrates forward-only at startup.