add: forgejo overwrite #30

2023-01-09T15:48:41Z

yksflip commented

2023-01-09 15:48:41 +00:00

this adds a overwrite file that uses the forgejo docker image instead of giteas.
I think atm this would be the simplest way to migrate gitea instance to forgejo. But maybe in future forgejo could diverge further from gitea and a seperate recipe repo would make more sense? Also versioning is probably weird this way ...

happy for feedback!

this adds a overwrite file that uses the forgejo docker image instead of giteas. I think atm this would be the simplest way to migrate gitea instance to forgejo. But maybe in future forgejo could diverge further from gitea and a seperate recipe repo would make more sense? Also versioning is probably weird this way ... happy for feedback!

decentral1se approved these changes 2023-01-09 22:32:21 +00:00

decentral1se left a comment

LGTM! Given the experience of trying to maintain both Mastodon/Hometown recipes as seprate repositories, it doesn't really work out well, e.g. the Mastodon recipe is kinda a bit behind but the hometown is updated. So, this seems like a nice way to avoid a new out-of-sync fork situation. Also, there are some uncertainties around Forgejo as a new project, so this seems like an easy way to test it out.

👍 1

3wordchant referenced this pull request from toolshed/recipes-wishlist

2023-01-20 00:33:52 +00:00

forgejo, soft fork of gitea #83

mayel commented

2023-01-20 00:37:28 +00:00

oh great to see! btw this approach would also work:
image: ${APP_DOCKER_IMAGE} and in the .env simply APP_DOCKER_IMAGE=codeberg.org/forgejo/forgejo:1.18.0-1-rootless or the gitea one by default I guess

oh great to see! btw this approach would also work: `image: ${APP_DOCKER_IMAGE}` and in the .env simply `APP_DOCKER_IMAGE=codeberg.org/forgejo/forgejo:1.18.0-1-rootless` or the gitea one by default I guess

3wordchant commented

2023-01-20 03:37:47 +00:00

@mayel I think we ideally want to keep a specific image in the main compose.yml to make versioning work for Gitea deployments, although allowing overriding using the approach you're suggesting could be helpful for a compose.somethingelse.yml maybe?

@mayel I think we ideally want to keep a specific image in the main `compose.yml` to make versioning work for Gitea deployments, although allowing overriding using the approach you're suggesting could be helpful for a `compose.somethingelse.yml` maybe?

mayel commented

2023-01-20 03:41:32 +00:00

@3wordchant yeah makes sens to have a yml override as there may end up being other differences too, just noting the feasibility (I use that to be able to specify a different images for a specific arch, when the main/official image isn't multiarch or does't include the one I need)

yksflip force-pushed add_forgejo from 3ab75d30a3 to b88bae051c

2023-01-20 09:55:22 +00:00

Compare

yksflip merged commit b88bae051c into master

2023-01-20 09:56:23 +00:00

yksflip deleted branch add_forgejo

2023-01-20 09:56:31 +00:00

yksflip commented

2023-01-20 09:57:20 +00:00

thanks for the feedback :)

Sign in to join this conversation.

4 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: coop-cloud/gitea#30