feat: add Yami dev stack module (on-demand gitea+postgres+docker+runner) #3

Merged
Chexit merged 1 commits from claude/add-yami-dev-stack-zHOMn into master 2026-04-18 23:58:52 +00:00
Chexit commented 2026-04-18 23:10:08 +00:00 (Migrated from github.com)

$(cat <<'EOF'

Summary

  • Добавлен модуль yami-dev-stack.nix — on-demand dev-стек для проекта Yami (стриминговый плеер для аниме)
  • Стек поднимается только вручную через yami-up, не стартует при загрузке системы
  • Удалена строка virtualisation.docker.enable = true из configuration.nix — docker теперь управляется модулем

Что включает модуль

  • systemd target yami-dev.target — ручной запуск всего стека одной командой
  • PostgreSQL 16 — БД и пользователь gitea, socket-аутентификация
  • Gitea — веб + встроенный SSH (порт 2222), LFS, Actions, Package Registry
  • DockerenableOnBoot = false, запускается только в составе target
  • Gitea Actions Runner — поддержка ubuntu-latest:docker://node:20 и native:host
  • Shell aliases: yami-up, yami-down, yami-status, yami-logs
  • Firewall: порты 3000 и 2222 открываются при включении модуля

Активация

Раскомментировать в configuration.nix:

# ./yami-dev-stack.nix

И добавить:

services.yami-dev-stack = {
  enable = true;
  user   = "chexit";
};

Затем sudo nixos-rebuild switch --flake .#chexit.

Test plan

  • nixos-rebuild switch без ошибок
  • yami-up поднимает Gitea на http://localhost:3000
  • yami-down останавливает весь стек
  • Docker не стартует при перезагрузке (без yami-up)
  • После получения токена раннера — раннер появляется в Gitea Admin → Actions

https://claude.ai/code/session_017dm8ypaaWNeA27ctmwq5dn
EOF
)

$(cat <<'EOF' ## Summary - Добавлен модуль `yami-dev-stack.nix` — on-demand dev-стек для проекта Yami (стриминговый плеер для аниме) - Стек поднимается **только вручную** через `yami-up`, не стартует при загрузке системы - Удалена строка `virtualisation.docker.enable = true` из `configuration.nix` — docker теперь управляется модулем ## Что включает модуль - **systemd target `yami-dev.target`** — ручной запуск всего стека одной командой - **PostgreSQL 16** — БД и пользователь `gitea`, socket-аутентификация - **Gitea** — веб + встроенный SSH (порт 2222), LFS, Actions, Package Registry - **Docker** — `enableOnBoot = false`, запускается только в составе target - **Gitea Actions Runner** — поддержка `ubuntu-latest:docker://node:20` и `native:host` - **Shell aliases**: `yami-up`, `yami-down`, `yami-status`, `yami-logs` - **Firewall**: порты 3000 и 2222 открываются при включении модуля ## Активация Раскомментировать в `configuration.nix`: ```nix # ./yami-dev-stack.nix ``` И добавить: ```nix services.yami-dev-stack = { enable = true; user = "chexit"; }; ``` Затем `sudo nixos-rebuild switch --flake .#chexit`. ## Test plan - [ ] `nixos-rebuild switch` без ошибок - [ ] `yami-up` поднимает Gitea на http://localhost:3000 - [ ] `yami-down` останавливает весь стек - [ ] Docker не стартует при перезагрузке (без `yami-up`) - [ ] После получения токена раннера — раннер появляется в Gitea Admin → Actions https://claude.ai/code/session_017dm8ypaaWNeA27ctmwq5dn EOF )
copilot-pull-request-reviewer[bot] (Migrated from github.com) reviewed 2026-04-18 23:56:30 +00:00
copilot-pull-request-reviewer[bot] (Migrated from github.com) left a comment

Pull request overview

Adds an optional NixOS module to spin up an on-demand local development stack for the Yami project (Gitea + PostgreSQL + Docker + Gitea Actions runner) controlled via a dedicated systemd target rather than starting on boot.

Changes:

  • Introduces yami-dev-stack.nix module with services.yami-dev-stack.enable/user options and a yami-dev.target to start/stop the stack manually.
  • Configures PostgreSQL 16 + Gitea (web/SSH/LFS/Actions/Packages) + Docker + Gitea Actions runner to be grouped under the target.
  • Updates configuration.nix to stop enabling Docker globally and to document how to enable the new module.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 6 comments.

File Description
yami-dev-stack.nix New NixOS module defining the on-demand Gitea/Postgres/Docker/runner stack and helper aliases/firewall rules.
configuration.nix Documents enabling the module and removes global Docker enablement in favor of module-managed Docker.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

## Pull request overview Adds an optional NixOS module to spin up an on-demand local development stack for the Yami project (Gitea + PostgreSQL + Docker + Gitea Actions runner) controlled via a dedicated systemd target rather than starting on boot. **Changes:** - Introduces `yami-dev-stack.nix` module with `services.yami-dev-stack.enable/user` options and a `yami-dev.target` to start/stop the stack manually. - Configures PostgreSQL 16 + Gitea (web/SSH/LFS/Actions/Packages) + Docker + Gitea Actions runner to be grouped under the target. - Updates `configuration.nix` to stop enabling Docker globally and to document how to enable the new module. ### Reviewed changes Copilot reviewed 2 out of 2 changed files in this pull request and generated 6 comments. | File | Description | | ---- | ----------- | | yami-dev-stack.nix | New NixOS module defining the on-demand Gitea/Postgres/Docker/runner stack and helper aliases/firewall rules. | | configuration.nix | Documents enabling the module and removes global Docker enablement in favor of module-managed Docker. | --- 💡 <a href="/Chexit/nix-config/new/master?filename=.github/instructions/*.instructions.md" class="Link--inTextBlock" target="_blank" rel="noopener noreferrer">Add Copilot custom instructions</a> for smarter, more guided reviews. <a href="https://docs.github.com/en/copilot/customizing-copilot/adding-repository-custom-instructions-for-github-copilot" class="Link--inTextBlock" target="_blank" rel="noopener noreferrer">Learn how to get started</a>.
copilot-pull-request-reviewer[bot] (Migrated from github.com) commented 2026-04-18 23:56:30 +00:00

Removing virtualisation.docker.enable = true; makes Docker unavailable unless the yami-dev-stack module is enabled. If Docker is still expected for other workflows on this host, consider leaving Docker enabled here and only controlling its on-demand start in the module, or clearly documenting that enabling yami-dev-stack is now required for any Docker usage.

  virtualisation.docker.enable = true;
  # yami-dev-stack.nix can be enabled optionally for the Yami dev stack.
Removing `virtualisation.docker.enable = true;` makes Docker unavailable unless the yami-dev-stack module is enabled. If Docker is still expected for other workflows on this host, consider leaving Docker enabled here and only controlling its on-demand start in the module, or clearly documenting that enabling yami-dev-stack is now required for any Docker usage. ```suggestion virtualisation.docker.enable = true; # yami-dev-stack.nix can be enabled optionally for the Yami dev stack. ```
@@ -0,0 +59,4 @@
server = {
DOMAIN = "localhost";
ROOT_URL = "http://localhost:3000/";
HTTP_ADDR = "0.0.0.0";
copilot-pull-request-reviewer[bot] (Migrated from github.com) commented 2026-04-18 23:56:30 +00:00

Binding the Gitea HTTP server to 0.0.0.0 and opening firewall ports makes this dev stack reachable from the network by default. For a local-only on-demand dev stack, prefer binding to 127.0.0.1 (or make the bind address / openFirewall behavior configurable via module options) to reduce accidental exposure.

          HTTP_ADDR        = "127.0.0.1";
Binding the Gitea HTTP server to `0.0.0.0` and opening firewall ports makes this dev stack reachable from the network by default. For a local-only on-demand dev stack, prefer binding to `127.0.0.1` (or make the bind address / openFirewall behavior configurable via module options) to reduce accidental exposure. ```suggestion HTTP_ADDR = "127.0.0.1"; ```
@@ -0,0 +61,4 @@
ROOT_URL = "http://localhost:3000/";
HTTP_ADDR = "0.0.0.0";
HTTP_PORT = 3000;
SSH_PORT = 2222;
copilot-pull-request-reviewer[bot] (Migrated from github.com) commented 2026-04-18 23:56:30 +00:00

Gitea built-in SSH server typically listens on SSH_LISTEN_PORT (default 22); setting only SSH_PORT = 2222 usually affects clone URL display, not the actual bind port. With START_SSH_SERVER = true this may try to bind to 22 and fail (or require extra privileges). Set SSH_LISTEN_PORT = 2222 (and optionally SSH_LISTEN_HOST) alongside SSH_PORT to ensure it actually listens on 2222.

          SSH_PORT         = 2222;
          SSH_LISTEN_PORT  = 2222;
Gitea built-in SSH server typically listens on `SSH_LISTEN_PORT` (default 22); setting only `SSH_PORT = 2222` usually affects clone URL display, not the actual bind port. With `START_SSH_SERVER = true` this may try to bind to 22 and fail (or require extra privileges). Set `SSH_LISTEN_PORT = 2222` (and optionally `SSH_LISTEN_HOST`) alongside `SSH_PORT` to ensure it actually listens on 2222. ```suggestion SSH_PORT = 2222; SSH_LISTEN_PORT = 2222; ```
@@ -0,0 +117,4 @@
wantedBy = mkForce [ "yami-dev.target" ];
partOf = [ "yami-dev.target" ];
};
copilot-pull-request-reviewer[bot] (Migrated from github.com) commented 2026-04-18 23:56:29 +00:00

For “manual-only” Docker, overriding only systemd.services.docker.wantedBy may not be sufficient if docker.socket is still enabled (socket activation can start dockerd without yami-dev.target). Verify whether virtualisation.docker.enableOnBoot = false disables the socket; if not, also adjust systemd.sockets.docker.wantedBy (or explicitly disable the socket) so Docker can’t start outside yami-dev.target.


    systemd.sockets.docker = {
      wantedBy = mkForce [ "yami-dev.target" ];
      partOf   = [ "yami-dev.target" ];
    };
For “manual-only” Docker, overriding only `systemd.services.docker.wantedBy` may not be sufficient if `docker.socket` is still enabled (socket activation can start dockerd without `yami-dev.target`). Verify whether `virtualisation.docker.enableOnBoot = false` disables the socket; if not, also adjust `systemd.sockets.docker.wantedBy` (or explicitly disable the socket) so Docker can’t start outside `yami-dev.target`. ```suggestion systemd.sockets.docker = { wantedBy = mkForce [ "yami-dev.target" ]; partOf = [ "yami-dev.target" ]; }; ```
@@ -0,0 +119,4 @@
};
users.users.${cfg.user}.extraGroups = [ "docker" ];
copilot-pull-request-reviewer[bot] (Migrated from github.com) commented 2026-04-18 23:56:29 +00:00

users.users.${cfg.user}.extraGroups = [ "docker" ]; will create/modify that user entry from this module. If cfg.user isn’t already defined elsewhere, this can lead to an invalid/incomplete user definition or unexpected user creation. Consider adding an assertion that the user exists (builtins.hasAttr cfg.user config.users.users) and use mkAfter to append the group instead of redefining the list.

    assertions = [
      {
        assertion = builtins.hasAttr cfg.user config.users.users;
        message = "services.yami-dev-stack.user must refer to an existing user defined in users.users";
      }
    ];

    users.users.${cfg.user}.extraGroups = mkAfter [ "docker" ];
`users.users.${cfg.user}.extraGroups = [ "docker" ];` will create/modify that user entry from this module. If `cfg.user` isn’t already defined elsewhere, this can lead to an invalid/incomplete user definition or unexpected user creation. Consider adding an assertion that the user exists (`builtins.hasAttr cfg.user config.users.users`) and use `mkAfter` to append the group instead of redefining the list. ```suggestion assertions = [ { assertion = builtins.hasAttr cfg.user config.users.users; message = "services.yami-dev-stack.user must refer to an existing user defined in users.users"; } ]; users.users.${cfg.user}.extraGroups = mkAfter [ "docker" ]; ```
@@ -0,0 +126,4 @@
name = "home-runner";
url = "http://localhost:3000";
tokenFile = "/var/lib/gitea-runner/token";
labels = [
copilot-pull-request-reviewer[bot] (Migrated from github.com) commented 2026-04-18 23:56:30 +00:00

services.gitea-actions-runner will fail to start if tokenFile doesn’t exist yet, which makes yami-up likely to report a failed unit on first run. Consider adding a systemd ConditionPathExists= (or similar gating) for gitea-runner-default so the rest of the target can start cleanly before the token is provisioned.

`services.gitea-actions-runner` will fail to start if `tokenFile` doesn’t exist yet, which makes `yami-up` likely to report a failed unit on first run. Consider adding a systemd `ConditionPathExists=` (or similar gating) for `gitea-runner-default` so the rest of the target can start cleanly before the token is provisioned.
Sign in to join this conversation.