split forgejo as it's own recipe #43
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
#42 (comment)
when app.ini start differing too much
I think it's good to start with a seperate forgejo recipe so that the recipe versioning is clearer. I made a fork here: https://git.coopcloud.tech/coop-cloud/forgejo
@p4u1 awesome work! Should we consider removing
compose.forgejo.ymlfrom this repo, and adding a release note / note in README?great!! now for the migration process... do i need to move volumes or are they going to be kept since the app name/domain is the same?
@fauno by default, secrets and volume names are based on
STACK_NAMEwhich is based on app domain – so that aspect of the migration should "just work".The main migration challenge I can think of is versioning / upgrading.
If someone has
TYPE=gitea:3.5.2+1.24.2-rootlessand they change toTYPE=forgejo– should they keep the version number? Drop it? And any advice we can give them about when and whether toundeploy/redeploy, or justdeploy -f?So bassically when migrating to the new forgejo recipe you should upgrade to https://git.coopcloud.tech/coop-cloud/forgejo/releases/tag/4.0.2+12.0.2-rootless while following the release notes in https://git.coopcloud.tech/coop-cloud/forgejo/src/branch/main/release/4.0.0+12.0.2-rootless
I really had hard troubles with
deploy -fon the recipe but that was also before on the gitea recipe. Haven't had a chance to investigate yetmmm what i did is to undeploy, diff the env files from recipe and app, change TYPE to forgejo without commit/tag and redeploy. it worked!
Is there anything else to do here? Can we close it?
ok!