Community生产力与协作github.com

NixOS/anixpkgs 编辑-部署-测试

用于修改或部署 NixOS 配置或任何 anixpkgs 包/模块时使用。涵盖编辑-部署-测试工作流和常见陷阱。

anixpkgs 编辑-部署-测试 是什么?

该技能专为管理 NixOS 系统的开发者设计,所有系统配置都存储在 `anixpkgs` 仓库中,该仓库在多个路径(如 `~/sources/anixpkgs`)克隆。工作流遵循“编辑-部署-测试”循环:首先编辑 Nix 模块或 Python/shell 脚本,然后使用 `git add` 暂存新文件(`git-cc` 只复制跟踪的文件),最后通过本地 `anix-upgrade-ui` API 部署,首选流式 HTTP POST 请求(支持 `local` 选项以确保模块变更生效)。测试在部署后直接在机器上验证,确保变更生效。该技能支持所有运行 `anix-upgrade-ui` 的机器,API 无需身份验证,可通过 `.local` 主机名访问。关键注意点包括:NixOS 模块必须在正确位置导入(如 `pc-base.nix` 的导入列表),新选项需在 `opts.nix` 声明并在 `pc-base.nix` 赋值。远程部署时,应传递完整的提交哈希(`commit`)而非分支,以避免 CDN 缓存的陈旧 tarball。同时,MCP 服务器需要按用户注册,并通过 `claude-setup` 脚本重新运行。监控部署运行可通过 API 获取状态、流式日志或完整日志。

兼容平台✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/goromal/agent-skills/tree/HEAD/skills/anixpkgs-deploy

Installed? Explore more 生产力与协作 skills: steipete/gemini, steipete/gh-issues, steipete/skill-creator · View all 6 →

在你喜欢的 AI 中提问

打开一个已预加载此 Agent Skill 的新对话。

文档

本机器运行 NixOS;所有系统配置均位于 anixpkgs 仓库中,该仓库克隆在 ~/sources/anixpkgs(规范路径)以及其他可能路径(例如 /data/andrew/dev/claude/sources/anixpkgs)。当前树通过其 flake 配置部署;anix-upgrade 为旧树保留基于 channel 的路径。

工作流

  1. 编辑 pkgs/ 下相关的 Nix 模块或 Python/shell 脚本。
  2. 暂存新文件 — git-cc(由 anix-upgrade 使用)仅复制已跟踪的文件(git ls-files)。对于新文件,请先执行 git add,否则它们将在构建中静默缺失。
  3. 部署 通过本地 anix-upgrade-ui API(首选),流式传输直到完成:
    upgrade_host="$(hostname).local"
    curl -si "http://${upgrade_host}/anix-upgrade/api/v1/run" -X POST \
      -H 'Content-Type: application/json' \
      -d '{"source": "/path/to/anixpkgs", "local": true}'
    # 202 → {"run_id": "<uuid>", "started": true};  409 → 已在运行
    curl -N "http://${upgrade_host}/anix-upgrade/api/v1/stream/<run_id>"
    # 以 [UPGRADE SUCCESSFUL] 或 [UPGRADE FAILED (exit N)] 结束,随后 [DONE]
    
    使用机器的 .local 主机名,而不是 localhost:nginx 仅在此机器特定的虚拟主机上暴露此路由。 CLI 回退(仅在 API 不可达时):anix-upgrade --local -s /path/to/anixpkgs。
  4. 测试 结果在本机器上提交之前进行。

当变更涉及服务包或 NixOS 模块时,"local": true 是必须的 — 没有此选项,anix-upgrade 会将 dependencies.nix 中的 local-build = false 保留,因此模块的 cfg.package 默认解析为已发布标签的二进制文件,变更静默不生效。

重要陷阱

  • NixOS 模块必须在正确位置导入(例如 pc-base.nix 的 imports 列表)— 仅仅添加文件是不够的。
  • 新选项必须在 pkgs/nixos/components/opts.nix 中声明,并在 pc-base.nix 中赋值,然后在 base-dev-pkgs.nix 等组件中使用。
  • MCP 服务器通过 claude mcp add -s user ... 按用户注册;claude-setup 脚本(位于 base-dev-pkgs.nix 中)处理此操作,并且在添加服务器后必须重新运行。

部署到其他机器 / API 参考

同一 API 运行在每台托管 anix-upgrade-ui 的机器上:http://<hostname>.local/anix-upgrade/api/v1/(无需认证)。run 请求体字段(均为可选):version、commit、branch、source(本地路径)、local、boot — 语义与 anix-upgrade 标志相同。使用 -si 以便显示响应头部(某些代理会剥离 -s 的 JSON 体)。

对于远程机器,先推送更改并传递 commit(完整哈希),而不是 branch — 分支 tarball 是 CDN 缓存的,即使使用 --tarball-ttl 0 也可能在几分钟内是过时的;提交哈希使用内容寻址的 fetchGit,绕过 CDN:

curl -si -X POST http://<hostname>.local/anix-upgrade/api/v1/run \
  -H 'Content-Type: application/json' \
  -d "{\"commit\": \"$(git rev-parse HEAD)\", \"local\": true}"

监控运行(一旦新运行开始,run_id 会返回 404,因此在重新触发前抓取日志):

curl -s  .../api/v1/status/<run_id> | jq .   # status: running|success|failed
curl -N  .../api/v1/stream/<run_id>          # SSE: 重播最后 512 KB,然后实时
curl -o upgrade.log .../api/v1/log/<run_id>  # 完整日志

运行记录出现在浏览器 UI 的 http://<hostname>.local/anix-upgrade/ 上,带有 via API 徽章;每台机器一次只能有一个运行(API 和手动 UI 互斥)。

Individual skills in this repo

This repo contains 3 individual skills — each has its own dedicated page.

相关技能