split forgejo as it's own recipe #43

Closed
opened 2025-02-20 12:15:44 +00:00 by fauno · 9 comments
Owner

#42 (comment)

when app.ini start differing too much

https://git.coopcloud.tech/coop-cloud/gitea/pulls/42#issuecomment-22907 when app.ini start differing too much
Owner

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

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
Owner

@p4u1 awesome work! Should we consider removing compose.forgejo.yml from this repo, and adding a release note / note in README?

@p4u1 awesome work! Should we consider removing `compose.forgejo.yml` from this repo, and adding a release note / note in README?
Author
Owner

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?

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?
Owner

@fauno by default, secrets and volume names are based on STACK_NAME which 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-rootless and they change to TYPE=forgejo – should they keep the version number? Drop it? And any advice we can give them about when and whether to undeploy / redeploy, or just deploy -f?

@fauno by default, secrets and volume names are based on `STACK_NAME` which 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-rootless` and they change to `TYPE=forgejo` – should they keep the version number? Drop it? And any advice we can give them about when and whether to `undeploy` / `redeploy`, or just `deploy -f`?
Owner

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

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
Owner

And any advice we can give them about when and whether to undeploy / redeploy, or just deploy -f?

I really had hard troubles with deploy -f on the recipe but that was also before on the gitea recipe. Haven't had a chance to investigate yet

> And any advice we can give them about when and whether to undeploy / redeploy, or just deploy -f? I really had hard troubles with `deploy -f` on the recipe but that was also before on the gitea recipe. Haven't had a chance to investigate yet
Author
Owner

mmm 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!

mmm 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!
Owner

Is there anything else to do here? Can we close it?

https://git.coopcloud.tech/coop-cloud/forgejo

Is there anything else to do here? Can we close it? > https://git.coopcloud.tech/coop-cloud/forgejo
Author
Owner

ok!

ok!
fauno closed this issue 2026-01-07 13:03:29 +00:00
Sign in to join this conversation.
No Label
4 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: coop-cloud/gitea#43
No description provided.