WIP: Backup labels #9

Draft
wolcen wants to merge 9 commits from wolcen/hedgedoc:main into main
Member

Tested deploy & backup (have not yet apptempted restore).

Tested deploy & backup (have not yet apptempted restore).
wolcen added 5 commits 2022-12-16 20:52:28 +00:00
wolcen added 1 commit 2022-12-16 22:02:21 +00:00
continuous-integration/drone/pr Build is failing Details
d1335cacc9
Clean up inside container after backup
decentral1se approved these changes 2022-12-17 08:14:04 +00:00
decentral1se left a comment
Owner

LGTM 👍

LGTM 👍
compose.yml Outdated
@ -34,3 +34,3 @@
- internal
volumes:
- codimd_uploads:/home/hackmd/app/public/uploads
- codimd_uploads:/hedgedoc/public/uploads
Owner

Shall we do codimd_uploads -> hedgedoc_uploads also while we're here? Would be a breaking change on the recipe, people would need to migrate their volumes, but idk how many folks are using this right now? Up to you!

Shall we do `codimd_uploads` -> `hedgedoc_uploads` also while we're here? Would be a breaking change on the recipe, people would need to migrate their volumes, but idk how many folks are using this right now? Up to you!
Author
Member

I'm not personally sure it's worth breaking people's configs, but there are bigger issues than that, really. I'm a bit concerned about the existing deployments upgrade path - are there possibly upgrade hooks for this (for example, would be great to do a one-time tar/gz of the /hedgedoc/public/uploads if it is in the container)? People's volumes will be pointing to the incorrect folder, backups would not have been working, and just restarting the instance would kill their uploaded files otherwise, if I understand correctly?

Backups were not previously working (for me, at least), but at least this was what the recipe had reported, so hopefully no one was really trusting it for long-term pads (which we do intend to have).

FWIW, all the env vars for hedgedoc use codi's old "CMD_" prefixes, but it would probably be nice to see hedgedoc_uploads in your volume list.

If you'd prefer, I can do them in a different merge/pr, but I'm changing a few more things - I've added a health check for Postgres, and another CMD_ setting that I'll be using - I'm a little unclear how the versioning works at present, but just a note that if it'll require another version, more settings are inbound, one of which is the session secret in order to maintain logins between restarts.

I'm not personally sure it's worth breaking people's configs, but there are bigger issues than that, really. I'm a bit concerned about the existing deployments upgrade path - are there possibly upgrade hooks for this (for example, would be great to do a one-time tar/gz of the /hedgedoc/public/uploads if it is in the container)? People's volumes will be pointing to the incorrect folder, backups would not have been working, and just restarting the instance would kill their uploaded files otherwise, if I understand correctly? Backups were not previously working (for me, at least), but at least this was what the recipe had reported, so hopefully no one was really trusting it for long-term pads (which we do intend to have). FWIW, all the env vars for hedgedoc use codi's old "CMD_" prefixes, but it would probably be nice to see hedgedoc_uploads in your volume list. If you'd prefer, I can do them in a different merge/pr, but I'm changing a few more things - I've added a health check for Postgres, and another CMD_ setting that I'll be using - I'm a little unclear how the versioning works at present, but just a note that if it'll require another version, more settings are inbound, one of which is the session secret in order to maintain logins between restarts.
Owner

Oh yeh, v reasonable, maybe bundling all your changes into a new major recipe release version is the way to go? The upgrade paths are sometimes a bit ad-hoc yeh, so we have this "release notes" feature 👉 https://docs.coopcloud.tech/maintainers/handbook/#how-do-i-write-version-release-notes 👈 You can write a short guide which will turn up in the shell when people run upgrade and realise they need to do some work before doing the upgrade. Anyway, up to you!

Oh yeh, v reasonable, maybe bundling all your changes into a new major recipe release version is the way to go? The upgrade paths are sometimes a bit ad-hoc yeh, so we have this "release notes" feature 👉 https://docs.coopcloud.tech/maintainers/handbook/#how-do-i-write-version-release-notes 👈 You can write a short guide which will turn up in the shell when people run `upgrade` and realise they need to do some work before doing the upgrade. Anyway, up to you!
decentral1se changed title from main to Backup labels 2022-12-17 08:14:25 +00:00
Owner

Coming back to this @wolcen, any updates?

Coming back to this @wolcen, any updates?
wolcen added 8 commits 2023-07-28 21:25:53 +00:00
wolcen changed title from Backup labels to WIP: Backup labels 2023-07-28 21:26:50 +00:00
wolcen force-pushed main from 6bdde4622d to 1a2b3b9899 2023-07-28 21:43:38 +00:00 Compare
wolcen force-pushed main from 1a2b3b9899 to d299d5461d 2023-10-26 21:07:03 +00:00 Compare
wolcen added 1 commit 2023-10-26 21:23:44 +00:00
Some checks failed
continuous-integration/drone/pr Build is failing
This pull request has changes conflicting with the target branch.
  • compose.yml
You can also view command line instructions.

Step 1:

From your project repository, check out a new branch and test the changes.
git checkout -b wolcen-main main
git pull main

Step 2:

Merge the changes and update on Gitea.
git checkout main
git merge --no-ff wolcen-main
git push origin main
Sign in to join this conversation.
No reviewers
No Milestone
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: coop-cloud/hedgedoc#9
No description provided.