nixos/forgejo: fork from nixos/gitea (split)

[emilylange]

Description of changes

See

• nixos/gitea: reconcile module requirements for forgejo #244866

The new nixos/forgejo module is a slightly refactored version of nixos/gitea, but stays as compatible as possible for now.
With the exception being completely removing the already deprecated cfg.extraConfig and cfg.database.password options.

Migrating an existing forgejo instance using nixos/gitea needs to be done manually.
Mainly, moving /var/lib/gitea to /var/lib/forgejo and, in case of PSQL/MySQL either renaming the database or changing the cfg.database.name option to "gitea".

But it has yet to be decided where to put detailed migration instructions.

In the future, nixos/forgejo and nixos/gitea will further diverge.

And it would probably make sense to have a little warning/trace/hint in nixos/gitea when cfg.package = pkgs.forgejo` is used, so users are made aware of the new nixos/forgejo module and don't report issues to nixos/gitea anymore.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 23.11 Release Notes (or backporting 23.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

[bendlas]

I switched my forgejo instance from the gitea module to this module. Everything seems to be in order.

[bendlas]

Migrating an existing forgejo instance using nixos/gitea needs to be done manually.

Here are the steps that worked for me:

• stop service
• move state dir
• rename database user
• rename database
• switch
• chown state dir to forgejo user
• restart service

roughly (from memory; for postgres backend)

systemctl stop gitea
mv /var/lib/gitea /var/lib/forgejo
runuser -u postgres -- psql -c '
  ALTER USER gitea RENAME TO forgejo;
  ALTER DATABASE gitea RENAME TO forgejo;
'
nixos-rebuild switch
chown -R forgejo:forgejo /var/lib/forgejo
systemctl restart forgejo

[bendlas]

been running on this for a few weeks now, and I think it's ready

[emilylange]

@ofborg test forgejo

[SuperSandro2000]

Migrating an existing forgejo instance using nixos/gitea needs to be done manually. Mainly, moving /var/lib/gitea to /var/lib/forgejo and, in case of PSQL/MySQL either renaming the database or changing the cfg.database.name option to "gitea".

But it has yet to be decided where to put detailed migration instructions.

I don't understand why this was done. This makes migrating from gitea to forgejo unnecessarily hard for no technically reason. I could still just change services.gitea.package to forgejo and it would probably just work out of the box.

In the future, nixos/forgejo and nixos/gitea will further diverge.

This is what we are being told for almost a year now but I don't see it coming. The promised features like federation are still not available and forgejo is right now mostly a reskin of gitea with some detail changes.

What I am trying to express is that I am rather disappointed with the current situation.

[bendlas]

@SuperSandro2000 noted. I understand your frustration with this, but I can only ask you to propose any improvement that you may have, in a fresh issue.

[schmittlauch]

IMHO this is a breaking change or at least important-enough module addition that it should provide corresponding release notes entries.
Those currently running forgejo in NixOS stable are very likely to do this via customising services.gitea.package right now. If they should move to the dedicated forgejo module, they

1. need to be aware of it existing now; and
2. need to manually migrate certain state directories to a new name and permissions (which ones?)

I do understand the concern of forgejo becoming incompatible (enough) at some future point mandating a dedicated module. With the software being well compatible still, that could even be a good reason to do this now.
But requiring a manual intervention for today's forgejo users just for the sake of potential & future incompatibilites that might require manual interventions, is an interesting approach. This shifts the need for manual intervention to a stage where we don't even now whether this could save only potential future efforts, and thus IMHO wrongly preemptive.

If the forgejo-with-gitea-module to forgejo-with-forgejo-moduel was either automatic or at least trivially smooth, I'd be more welcoming of this module fork though.

[bendlas]

@schmittlauch This is not a breaking change, since it does not break anything that would have worked otherwise.
cc @SuperSandro2000 Maybe this explaination can also address some of your concerns about making migrating from gitea to forgejo unnecessarily hard for no technical reason

I have typed out migration instructions above. My intention is to verify these on another machine, and then prepare release notes alongside a runtime warning for when services.gitea.package is overridden with forgejo.

I understand your concerns about smoothing out the migration path (and, in fact, share some of them), but I feel like we need to separate out the arguments a bit:

• right now, we expect the approach of dropping in the forgejo package to the gitea module, to keep working (mostly; as well as it did so far) for the time being (despite forgejo having stopped describing itself as a drop-in)
• if it stops working, you'd probably find yourself in a conversation with the nixos gitea maintainers, who probably would point you to this module
• the only sense in which this could conceivably be a breaking change is in the social sense, where gitea maintainers will probably be slightly less interested in dealing with your forgejo problems
• hence, I don't share the sense of urgency, that your post seems to be conveying

All that said: I share your interest in getting in proper release notes and documenting the migration path, and if you have a good idea on where to put that migration script, I'd be grateful.

I don't share your concerns about needing manual intervention: You can, in fact, configure the forgejo module such that it would use the gitea user/database/folder, in order to migrate without requiring manual intervention at all. Thinking about it, that would probably be good to document that as another possible migration path.

In fact, despite having brought up this point myself before, I'm now more in favor of giving forgejo its separate infrastructure:

• this lessens the chance of accidentally stepping on gitea's toes or vice versa
• makes it easier to run gitea and forgejo side-by-side, when you're trying to decide which one to use
• makes it less confusing when trying to look into the folders/database
• so new-user experience would be a lot better, and IMO this trumps the need for existing users to look at docs when trying to do a voluntary migration

I'll try to get the forgejo module with all the docs sewn-up in time for this release, help is welcome.