add: forgejo overwrite #30
No reviewers
Labels
No Label
No Milestone
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: coop-cloud/gitea#30
Loading…
Reference in New Issue
No description provided.
Delete Branch "add_forgejo"
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?
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!
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.
oh great to see! btw this approach would also work:
image: ${APP_DOCKER_IMAGE}
and in the .env simplyAPP_DOCKER_IMAGE=codeberg.org/forgejo/forgejo:1.18.0-1-rootless
or the gitea one by default I guess@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 acompose.somethingelse.yml
maybe?@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)
3ab75d30a3
tob88bae051c
thanks for the feedback :)