nixos/forgejo: init

[Infinidoge]

Description of changes

Rebased #206493 to add the service using the already-merged package definition.

There are some pieces left over from the Gitea module (namely the renamed module definitions.)
These could be removed, since it is a new service, however I've gone ahead and left them in so switching from GItea -> Forgejo could just be a single rename in a user's configuration.

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.05 Release Notes (or backporting 22.11 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
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

[Infinidoge]

If anybody wants to be added as a maintainer to this, please let me know.
I am perfectly fine with maintaining it (and I certainly intend on using it, at least), however I'm not the most familiar with the Gitea/Forgejo codebase.

[SuperSandro2000]

I think we should keep this in the gitea module for now. The two programs are still almost identical right now and most of the code would be duplicated.

You can use forgejo by changing services.gitea.package to the forgejo package and since services.gitea.settings is freeform any new setting can be added.

[trepetti]

This actually does not work as the gitea service is currently written since the gitea binary name is hardcoded in even when the packages are switched out. Forgejo uses a forgejo binary.

[lilyinstarlight]

This actually does not work as the gitea service is currently written since the gitea binary name is hardcoded in even when the packages are switched out. Forgejo uses a forgejo binary.

Perhaps the module can be refactored to use lib.getExe cfg.package then everywhere instead of "${cfg.package}/bin/gitea" then? I don't see an immediate reason to add a new module for now, especially if it's mostly a copy of the gitea module

[trepetti]

Yes, that seems like a good idea. An additional option for a binaryName parameter may also do the trick.

[lilyinstarlight]

Yes, that seems like a good idea. An additional option for a binaryName parameter may also do the trick.

lib.getExe gets the meta.mainProgram attr on the package (falling back to the package name if absent), so it should be able to stand in for all intended use-cases. But I also don't feel strongly either way so someone else can argue to include such an option as well

Edit: And if using lib.getExe, someone can just override meta.mainProgram if they really need on the package instead of specifying it as a module attr

[trepetti]

That does seem like the way to go then.

[Infinidoge]

Yeah using getExe would work.
If we want to look to the future, we could have services.forgejo serve as an alias to services.gitea with the Forgejo package selected, but I don't know if that is a good idea

[lilyinstarlight]

It looks like this has been superseded by #218269. Feel free to re-open a new PR if you had any plans other than just adding lib.getExe