fix(connectors): fall back to user-level npm prefix when global dir not writable - #406
Merged
Merged
Conversation
…s not writable Octop often runs as a non-root user on NAS/container hosts where the npm global prefix (/usr/local) is not writable, so `npm install -g @wecom/cli` fails with EACCES (exit 243). This change: - Detects the configured npm global prefix and its writability before installing connector CLIs (wecom-cli / lark-cli) - Falls back to a user-level prefix (~/.npm-global) with --prefix when the global dir is not writable, without touching the user's npmrc - Injects the user-level npm bin dir into the in-process PATH at server startup and on status checks, so shutil.which and CLI subprocess calls find the binaries - Adds unit tests covering the fallback, the writable-path behavior and the PATH injection (cross-platform, honors USERPROFILE on Windows)
veenyi
added a commit
to veenyi/octop-fnos
that referenced
this pull request
Aug 25, 2026
… tighten process kill Addresses review feedback: - Extract find_python312 / fix_ownership_and_perms / free_octop_ports into a single shared library scripts/fnos/common.sh (injected into both packages' cmd/common.sh by build-fpk.sh at package time) instead of duplicating them across 7 docker/native lifecycle scripts - Tighten the leftover-process cleanup: only kill processes under this install dir (TRIM_APPDEST), no more broad 'pgrep -f octop' that could kill other users' / other installs' processes - Root README: add an 'FnOS Installation' section pointing to fnos/README.md and noting the initial credentials + the TencentCloud#406 dependency for non-root CLI installs
jubaoliang
pushed a commit
that referenced
this pull request
Aug 25, 2026
* feat(fnos): add FnOS (飞牛 NAS) app packaging for Docker and native installs Adds the packaging tree to build Octop as a FnOS app center package (.fpk): - fnos/: Docker-deployable FPK (thin wrapper that runs the Octop image via docker-compose on the NAS) - fnos-native/: native FPK that runs Octop directly on the FnOS host with the system Python 3.12 runtime (no Docker required) - scripts/build-fpk.sh: generic FPK build helper using the official fnpack CLI (injects the version from pyproject.toml into the manifest) Both packages share the same app version as pyproject.toml. Container image name is referenced as ghcr.io/TencentCloud/octop:latest — maintainers can republish under their own namespace; the per-repo CI (image build + release workflow) is intentionally left out of this PR. * feat(fnos): first-use guide — fixed initial credentials admin/Octop123 with docs - The previous default password 'octop' does not satisfy the password policy (>=8 chars incl. letters and digits) enforced by 'octop init', so the bootstrap admin could not be created - Switch the default to Octop123, identical to the official Docker image - Manifest install text now prints the initial account/password and tells users to change it after first login - fnos/README.md gains a 'First use' section (credentials table + change password guidance) so users never need to dig into data directories * ci(fnos): add FnOS packaging pipeline as a fork-maintainer template Provides a complete CI template that builds the Octop Docker image, the Docker .fpk and the native .fpk, then publishes GitHub releases (fixed version + rolling latest): - Trigger: workflow_dispatch only, so it never auto-runs on upstream - Image namespace referenced as ghcr.io/TencentCloud/octop (placeholder; fork maintainers replace with their own) - Iteration numbering, changelog generation (install-first, no-merges, capped at 30 entries) and rolling release management included * refactor(fnos): dedupe lifecycle scripts into scripts/fnos/common.sh; tighten process kill Addresses review feedback: - Extract find_python312 / fix_ownership_and_perms / free_octop_ports into a single shared library scripts/fnos/common.sh (injected into both packages' cmd/common.sh by build-fpk.sh at package time) instead of duplicating them across 7 docker/native lifecycle scripts - Tighten the leftover-process cleanup: only kill processes under this install dir (TRIM_APPDEST), no more broad 'pgrep -f octop' that could kill other users' / other installs' processes - Root README: add an 'FnOS Installation' section pointing to fnos/README.md and noting the initial credentials + the #406 dependency for non-root CLI installs * feat(fnos): transparent app icons (512/256/64) — remove white background for dark/light themes --------- Co-authored-by: veenyi <veenyi@users.noreply.github.com>
Contributor
Author
|
说明：为方便中文团队沟通，本 PR 描述已更新为中文。后续讨论请直接使用中文。 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
问题
Octop 常以非 root 用户运行在 NAS / 容器主机（如飞牛 FnOS 应用中心服务）上，此时 npm 全局目录（
/usr/local）不可写。点击连接器的"安装 CLI"执行npm install -g @wecom/cli会失败：导致企微 / 飞书连接器 CLI 在这些环境无法安装。
修复
npm config get prefix）并检测是否可写。--prefix ~/.npm-global安装到用户级目录（无需 sudo、不修改用户 npmrc）。shutil.which和连接器 CLI 子进程都能找到命令。expanduser）。说明
纯 bugfix：全局目录可写时（常见 Docker 场景）行为完全不变。CI 全绿（Linux + Windows）。