指标监控监控大盘CLI告警MCP 服务【免费下载链接】glancesGlances an Eye on your system. A top/htop alternative for GNU/Linux, BSD, macOS and Windows operating systems.项目地址https://gitcode.com/gh_mirrors/gl/glances点击查看免费下载本篇技术指南以 Glances 官方贡献文档CONTRIBUTING.md为主体系统讲解向这个跨平台系统监控工具提交贡献的完整流程如何正确使用 Issue 跟踪器提交 Bug 报告与功能需求、如何遵循 develop 分支工作流发起 Pull Request、如何执行 Ruff 格式化、单元测试与文档构建等质量门槛以及 LGPLv3 许可下的贡献授权约定。读完本文你将掌握一套可直接落地的开源协作实操方案能够以符合项目规范的方式为 Glances 贡献代码、文档与测试用例。贡献前的准备先了解项目协作约定Glances 是一个用 Python 编写、基于 psutil 的跨平台系统监控工具覆盖 GNU/Linux、BSD、macOS 与 Windows。向这样一个维护活跃、插件众多的项目贡献代码首先要理解它对协作流程的基本期待Issue 跟踪器GitHub Issues是 Bug 报告、功能请求Feature Requests和 Pull Request 的首选通道不要用 Issue 跟踪器处理个人使用支持类问题官方维护有专门的用户问答论坛不要在 Issue 里偏离主题讨论应聚焦于问题本身尊重他人观点大改动先问再动手实现新功能、重构代码或移植到其他语言之前务必先在 Issue 中与维护者沟通避免投入大量时间做维护者不打算合并的工作。这些约定既是流程约束也体现了项目的协作价值观通过规范的沟通方式尊重维护者与其他贡献者的时间。Bug 报告如何写出能被快速定位的 IssueGood bug reports 对开源项目极其宝贵。Glances 贡献文档给出了四条核心准则先搜索使用 GitHub Issue 搜索功能确认该问题是否已被报告确认是否已修复尝试用仓库最新的master或develop分支复现问题隔离问题理想情况下构建一个最小化测试环境提供测试环境信息操作系统名称与版本、Glances 版本等。文档还给出了一个标准的 Bug 报告模板包含以下要素简短且描述性的 Bug 报告标题。Glances 与 psutil 的版本通过glances -V获取。操作系统描述名称与版本。问题摘要及发生问题的 OS 环境。若合适附上复现步骤。第一步第二步后续步骤截图如有帮助。其他相关信息例如你定位到的疑似导致问题的代码行、潜在的解决方案等。用调试模式与 --issue 选项收集诊断信息贡献文档特别强调两种诊断手段-d调试模式运行 Glances 的 debug 模式输出详细日志--issue选项Glances 3.2.0 及以上版本内置的问题诊断工具运行后会输出一份结构化的诊断报告直接复制其输出粘贴到 Issue 中即可。从源码看--issue模式由 glances_stdout_issue.py 中的GlancesStdoutIssue类实现它在 standalone.py 中被调度serve_issue方法。该工具会依次执行以下动作打印环境版本信息Glances 版本及其可执行文件真实路径、Python 版本与解释器路径、PsUtil 版本与模块路径遍历所有已启用的插件逐个调用update()并计时对每个插件输出[OK]含耗时或[ERROR]含异常信息状态被禁用的插件显示[NA]汇总所有插件更新总耗时并列出Top 10 最慢插件排名。这个输出对维护者非常有价值既能确认环境版本是否匹配也能一眼看出是哪个插件抛异常、哪个插件存在性能瓶颈。这也是为什么贡献文档要求提交者请使用它并复制粘贴输出。同时将glances.conf配置内容一并附上可参考 conf/glances.conf有助于复现配置相关的问题。功能请求把想法转化为可讨论的提案Glances 欢迎功能请求但要求贡献者先花时间确认自己的想法是否符合项目范围与目标。这需要由你自己来论证该功能的价值——文档原话是Its up toyouto make a strong case to convince the projects developers。建议在提案中提供尽可能多的细节与上下文该功能解决什么真实痛点、与现有插件体系如何衔接、是否需要新增可选依赖等以便维护者评估。Pull Request 工作流从 Fork 到合并的九步走所有 Pull Request 都应基于develop分支。代码必须符合 PEP8 规范提交前用 PEP 校验器检查并通过单元测试。完整流程如下1. Fork 项目并配置远程仓库# 将你的 fork 克隆到当前目录 git clone https://github.com/your-username/glances.git # 进入新克隆的目录 cd glances # 将原仓库设为名为 upstream 的远程仓库 git remote add upstream https://github.com/nicolargo/glances.git2. 同步上游最新代码git checkout develop git pull upstream develop3. 创建主题分支基于主开发分支创建新分支最佳实践是命名为 issue 编号如issue#xxxgit checkout -b topic-branch-name4. 编码遵循项目采用的 Python 代码风格约定Elements of Python Style保持改动聚焦避免夹带无关提交。5. 用 Makefile 验证代码Glances 的 Makefile 提供了完整的开发验证入口贡献文档明确列出目标作用make format用 Ruff linter 格式化代码make run运行 Glances控制台/standalone 模式make run-webserver以 Web Server 模式运行 Glancesmake test运行单元测试make docs更新文档make webui重新编译 Web UI从 Makefile 源码看这些目标背后是完整的工具链make format执行ruff format .对应 pyproject.toml 中[tool.ruff]配置的 120 字符行宽与 py310 目标版本make test执行pytest运行整个 tests 目录下的测试套件make docs则会先通过--api-doc与--api-restful-doc自动生成 API 文档再调用 docs/Makefile 中的 Sphinx 构建流程。6. 分逻辑块提交提交信息遵循 Git commit message 规范并用 Git interactive rebase 整理提交再公开推送。7. 合并或变基上游 develop 分支git pull [--rebase] upstream develop8. 推送主题分支到你的 forkgit push origin topic-branch-name9. 发起 Pull Request针对develop分支发起 PR标题与描述清晰明确。IMPORTANT提交补丁即表示你同意项目所有者依据 LGPLv3见 COPYING许可你的工作成果涉及代码变更时。代码质量门槛Ruff、单元测试与 pre-commit 钩子贡献文档要求使用 PEP8 兼容的代码并在提交前使用 PEP 校验器同时运行单元测试脚本。当前仓库实际采用Ruff作为统一的格式与检查工具其规则配置在 pyproject.toml 中[tool.ruff]行宽 120、目标 Python 版本 3.10[tool.ruff.lint]启用 pycodestyleE/W、PyflakesF、isortI、pep8-namingN、mccabe 圈复杂度C90等规则最大圈复杂度阈值 21。仓库还提供了 .pre-commit-config.yaml集成了一整套自动化质量门禁包括gitleaks检测硬编码密钥Ruffruff-format与ruff-check带--fix自动修复check-jsonschema校验 GitHub Actions 工作流文件shellcheck / bashate检查 shell 脚本语法与风格pre-commit-hooks校验 Python AST、docstring 位置、JSON/TOML/YAML 语法、调试语句残留、私钥泄漏、大文件超过 5MB 拒绝提交、重复行等本地钩子调用 find-duplicate-lines.sh 检查文件末尾重复行。在make venv-dev创建开发环境时会执行pre-commit install --hook-type pre-commit自动安装这些钩子见 Makefile 的venv-dev目标让每次git commit前都自动完成一轮质量检查。单元测试pytest 体系与测试组织贡献文档要求提交 PR 前通过单元测试对应仓库中的make test即pytest。测试集中在 tests 目录覆盖了核心模块、全部插件、REST/XMLRPC API、WebUI、内存泄漏与性能等维度。Makefile 还提供了细粒度的测试入口make test-core核心模块测试tests/test_core.pymake test-plugins全部插件测试tests/test_plugin_*.pymake test-api、make test-restful、make test-xmlrpc、make test-webui各类 API 与 WebUI 测试make test-memoryleak、make test-perf内存泄漏与性能测试make test-exports批量运行 tests 下的各类导出接口脚本测试CSV、JSON、InfluxDB v1/v3、TimescaleDB、NATS、ClickHouse 等。测试依赖统一通过 tests/conftest.py 提供的 pytest fixtures 组织例如glances_statsfixture 使用-C ./conf/glances.conf参数实例化GlancesMain与GlancesStats模拟真实启动场景glances_webserverfixture 则启动一个真实 Web Server 并等待其健康检查端点响应。此外 tox.ini 定义了从 py39 到 py313 的多版本测试矩阵运行核心测试用于跨 Python 版本验证兼容性。文档贡献编辑源文件而非生成产物Glances 的文档贡献有明确约定直接编辑文档源文件而不是生成的输出文件。源文件位于docs/与docs/man/目录develop 分支docs/下是按主题组织的.rst源文件如 docs/quickstart.rst、docs/config.rst、docs/api 与 docs/gw 等模块文档man 手册页源文件为 docs/man/glances.1。生成文档输出文件时按 docs/README.txt 的说明操作# 安装 Sphinx 与 RTD 主题首次 make venv # 或更新已有环境 make venv-upgrade # 进入 docs 目录 cd docs # 构建 HTML 文档 make html # 构建 man 手册页 LC_ALLC make man其中docs/Makefile使用../.venv/bin/sphinx-build作为构建器make man会把生成的 man 页复制到docs/man/。注意make docs目标会自动根据--api-doc输出重写 docs/api/python.rst 与 docs/api/restful.rst因此贡献 API 相关文档时应理解这些文件的生成性质。结语一次合格的 Glances 贡献是什么样综合上述约定一次合格的 Glances 贡献可以概括为先在 Issue 中沟通想法 → 基于develop分支创建以 issue 编号命名的主题分支 → 编写符合 PEP8/Ruff 规范的聚焦改动 → 通过make format、make test及 pre-commit 钩子验证 → 按规范提交并 rebase 上游 → 向develop分支发起描述清晰的 PR。对于 Bug 报告善用-d调试模式与--issue诊断工具其输出包含环境版本、各插件 OK/ERROR 状态与耗时排名能大幅提升维护者的定位效率。遵循这套流程既是对维护者时间的尊重也是你的代码与文档成果被顺利合并的最大保障。赞分享指标监控监控大盘CLI告警MCP 服务【免费下载链接】glancesGlances an Eye on your system. A top/htop alternative for GNU/Linux, BSD, macOS and Windows operating systems.项目地址https://gitcode.com/gh_mirrors/gl/glances点击查看免费下载相关推荐NetBox 贡献指南从 Bug 报告到 Pull Request 的完整协作流程NetBox 贡献指南从 Bug 报告到 Pull Request 的完整协作流程 NetBox 是一个开源的网络基础设施管理IPAM/DCIM平台其代后端网络数据建模Tokio Issue 贡献指南从 Bug 报告到 Pull Request 的完整协作流程Tokio Issue 贡献指南从 Bug 报告到 Pull Request 的完整协作流程 本文是 Tokio 异步运行时Rust 生态中最具代表性的异步后端异步编程通信并发编程Serial Studio 贡献指南从报告 Bug 到合入 Pull Request 的完整协作流程Serial Studio 贡献指南从报告 Bug 到合入 Pull Request 的完整协作流程 Serial Studio 是一个开源的遥测数据可视化平桌面应用数据可视化物联网创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Glances 贡献指南：从 Bug 报告到 Pull Request 的完整协作流程
指标监控监控大盘CLI告警MCP 服务【免费下载链接】glancesGlances an Eye on your system. A top/htop alternative for GNU/Linux, BSD, macOS and Windows operating systems.项目地址https://gitcode.com/gh_mirrors/gl/glances点击查看免费下载本篇技术指南以 Glances 官方贡献文档CONTRIBUTING.md为主体系统讲解向这个跨平台系统监控工具提交贡献的完整流程如何正确使用 Issue 跟踪器提交 Bug 报告与功能需求、如何遵循 develop 分支工作流发起 Pull Request、如何执行 Ruff 格式化、单元测试与文档构建等质量门槛以及 LGPLv3 许可下的贡献授权约定。读完本文你将掌握一套可直接落地的开源协作实操方案能够以符合项目规范的方式为 Glances 贡献代码、文档与测试用例。贡献前的准备先了解项目协作约定Glances 是一个用 Python 编写、基于 psutil 的跨平台系统监控工具覆盖 GNU/Linux、BSD、macOS 与 Windows。向这样一个维护活跃、插件众多的项目贡献代码首先要理解它对协作流程的基本期待Issue 跟踪器GitHub Issues是 Bug 报告、功能请求Feature Requests和 Pull Request 的首选通道不要用 Issue 跟踪器处理个人使用支持类问题官方维护有专门的用户问答论坛不要在 Issue 里偏离主题讨论应聚焦于问题本身尊重他人观点大改动先问再动手实现新功能、重构代码或移植到其他语言之前务必先在 Issue 中与维护者沟通避免投入大量时间做维护者不打算合并的工作。这些约定既是流程约束也体现了项目的协作价值观通过规范的沟通方式尊重维护者与其他贡献者的时间。Bug 报告如何写出能被快速定位的 IssueGood bug reports 对开源项目极其宝贵。Glances 贡献文档给出了四条核心准则先搜索使用 GitHub Issue 搜索功能确认该问题是否已被报告确认是否已修复尝试用仓库最新的master或develop分支复现问题隔离问题理想情况下构建一个最小化测试环境提供测试环境信息操作系统名称与版本、Glances 版本等。文档还给出了一个标准的 Bug 报告模板包含以下要素简短且描述性的 Bug 报告标题。Glances 与 psutil 的版本通过glances -V获取。操作系统描述名称与版本。问题摘要及发生问题的 OS 环境。若合适附上复现步骤。第一步第二步后续步骤截图如有帮助。其他相关信息例如你定位到的疑似导致问题的代码行、潜在的解决方案等。用调试模式与 --issue 选项收集诊断信息贡献文档特别强调两种诊断手段-d调试模式运行 Glances 的 debug 模式输出详细日志--issue选项Glances 3.2.0 及以上版本内置的问题诊断工具运行后会输出一份结构化的诊断报告直接复制其输出粘贴到 Issue 中即可。从源码看--issue模式由 glances_stdout_issue.py 中的GlancesStdoutIssue类实现它在 standalone.py 中被调度serve_issue方法。该工具会依次执行以下动作打印环境版本信息Glances 版本及其可执行文件真实路径、Python 版本与解释器路径、PsUtil 版本与模块路径遍历所有已启用的插件逐个调用update()并计时对每个插件输出[OK]含耗时或[ERROR]含异常信息状态被禁用的插件显示[NA]汇总所有插件更新总耗时并列出Top 10 最慢插件排名。这个输出对维护者非常有价值既能确认环境版本是否匹配也能一眼看出是哪个插件抛异常、哪个插件存在性能瓶颈。这也是为什么贡献文档要求提交者请使用它并复制粘贴输出。同时将glances.conf配置内容一并附上可参考 conf/glances.conf有助于复现配置相关的问题。功能请求把想法转化为可讨论的提案Glances 欢迎功能请求但要求贡献者先花时间确认自己的想法是否符合项目范围与目标。这需要由你自己来论证该功能的价值——文档原话是Its up toyouto make a strong case to convince the projects developers。建议在提案中提供尽可能多的细节与上下文该功能解决什么真实痛点、与现有插件体系如何衔接、是否需要新增可选依赖等以便维护者评估。Pull Request 工作流从 Fork 到合并的九步走所有 Pull Request 都应基于develop分支。代码必须符合 PEP8 规范提交前用 PEP 校验器检查并通过单元测试。完整流程如下1. Fork 项目并配置远程仓库# 将你的 fork 克隆到当前目录 git clone https://github.com/your-username/glances.git # 进入新克隆的目录 cd glances # 将原仓库设为名为 upstream 的远程仓库 git remote add upstream https://github.com/nicolargo/glances.git2. 同步上游最新代码git checkout develop git pull upstream develop3. 创建主题分支基于主开发分支创建新分支最佳实践是命名为 issue 编号如issue#xxxgit checkout -b topic-branch-name4. 编码遵循项目采用的 Python 代码风格约定Elements of Python Style保持改动聚焦避免夹带无关提交。5. 用 Makefile 验证代码Glances 的 Makefile 提供了完整的开发验证入口贡献文档明确列出目标作用make format用 Ruff linter 格式化代码make run运行 Glances控制台/standalone 模式make run-webserver以 Web Server 模式运行 Glancesmake test运行单元测试make docs更新文档make webui重新编译 Web UI从 Makefile 源码看这些目标背后是完整的工具链make format执行ruff format .对应 pyproject.toml 中[tool.ruff]配置的 120 字符行宽与 py310 目标版本make test执行pytest运行整个 tests 目录下的测试套件make docs则会先通过--api-doc与--api-restful-doc自动生成 API 文档再调用 docs/Makefile 中的 Sphinx 构建流程。6. 分逻辑块提交提交信息遵循 Git commit message 规范并用 Git interactive rebase 整理提交再公开推送。7. 合并或变基上游 develop 分支git pull [--rebase] upstream develop8. 推送主题分支到你的 forkgit push origin topic-branch-name9. 发起 Pull Request针对develop分支发起 PR标题与描述清晰明确。IMPORTANT提交补丁即表示你同意项目所有者依据 LGPLv3见 COPYING许可你的工作成果涉及代码变更时。代码质量门槛Ruff、单元测试与 pre-commit 钩子贡献文档要求使用 PEP8 兼容的代码并在提交前使用 PEP 校验器同时运行单元测试脚本。当前仓库实际采用Ruff作为统一的格式与检查工具其规则配置在 pyproject.toml 中[tool.ruff]行宽 120、目标 Python 版本 3.10[tool.ruff.lint]启用 pycodestyleE/W、PyflakesF、isortI、pep8-namingN、mccabe 圈复杂度C90等规则最大圈复杂度阈值 21。仓库还提供了 .pre-commit-config.yaml集成了一整套自动化质量门禁包括gitleaks检测硬编码密钥Ruffruff-format与ruff-check带--fix自动修复check-jsonschema校验 GitHub Actions 工作流文件shellcheck / bashate检查 shell 脚本语法与风格pre-commit-hooks校验 Python AST、docstring 位置、JSON/TOML/YAML 语法、调试语句残留、私钥泄漏、大文件超过 5MB 拒绝提交、重复行等本地钩子调用 find-duplicate-lines.sh 检查文件末尾重复行。在make venv-dev创建开发环境时会执行pre-commit install --hook-type pre-commit自动安装这些钩子见 Makefile 的venv-dev目标让每次git commit前都自动完成一轮质量检查。单元测试pytest 体系与测试组织贡献文档要求提交 PR 前通过单元测试对应仓库中的make test即pytest。测试集中在 tests 目录覆盖了核心模块、全部插件、REST/XMLRPC API、WebUI、内存泄漏与性能等维度。Makefile 还提供了细粒度的测试入口make test-core核心模块测试tests/test_core.pymake test-plugins全部插件测试tests/test_plugin_*.pymake test-api、make test-restful、make test-xmlrpc、make test-webui各类 API 与 WebUI 测试make test-memoryleak、make test-perf内存泄漏与性能测试make test-exports批量运行 tests 下的各类导出接口脚本测试CSV、JSON、InfluxDB v1/v3、TimescaleDB、NATS、ClickHouse 等。测试依赖统一通过 tests/conftest.py 提供的 pytest fixtures 组织例如glances_statsfixture 使用-C ./conf/glances.conf参数实例化GlancesMain与GlancesStats模拟真实启动场景glances_webserverfixture 则启动一个真实 Web Server 并等待其健康检查端点响应。此外 tox.ini 定义了从 py39 到 py313 的多版本测试矩阵运行核心测试用于跨 Python 版本验证兼容性。文档贡献编辑源文件而非生成产物Glances 的文档贡献有明确约定直接编辑文档源文件而不是生成的输出文件。源文件位于docs/与docs/man/目录develop 分支docs/下是按主题组织的.rst源文件如 docs/quickstart.rst、docs/config.rst、docs/api 与 docs/gw 等模块文档man 手册页源文件为 docs/man/glances.1。生成文档输出文件时按 docs/README.txt 的说明操作# 安装 Sphinx 与 RTD 主题首次 make venv # 或更新已有环境 make venv-upgrade # 进入 docs 目录 cd docs # 构建 HTML 文档 make html # 构建 man 手册页 LC_ALLC make man其中docs/Makefile使用../.venv/bin/sphinx-build作为构建器make man会把生成的 man 页复制到docs/man/。注意make docs目标会自动根据--api-doc输出重写 docs/api/python.rst 与 docs/api/restful.rst因此贡献 API 相关文档时应理解这些文件的生成性质。结语一次合格的 Glances 贡献是什么样综合上述约定一次合格的 Glances 贡献可以概括为先在 Issue 中沟通想法 → 基于develop分支创建以 issue 编号命名的主题分支 → 编写符合 PEP8/Ruff 规范的聚焦改动 → 通过make format、make test及 pre-commit 钩子验证 → 按规范提交并 rebase 上游 → 向develop分支发起描述清晰的 PR。对于 Bug 报告善用-d调试模式与--issue诊断工具其输出包含环境版本、各插件 OK/ERROR 状态与耗时排名能大幅提升维护者的定位效率。遵循这套流程既是对维护者时间的尊重也是你的代码与文档成果被顺利合并的最大保障。赞分享指标监控监控大盘CLI告警MCP 服务【免费下载链接】glancesGlances an Eye on your system. A top/htop alternative for GNU/Linux, BSD, macOS and Windows operating systems.项目地址https://gitcode.com/gh_mirrors/gl/glances点击查看免费下载相关推荐NetBox 贡献指南从 Bug 报告到 Pull Request 的完整协作流程NetBox 贡献指南从 Bug 报告到 Pull Request 的完整协作流程 NetBox 是一个开源的网络基础设施管理IPAM/DCIM平台其代后端网络数据建模Tokio Issue 贡献指南从 Bug 报告到 Pull Request 的完整协作流程Tokio Issue 贡献指南从 Bug 报告到 Pull Request 的完整协作流程 本文是 Tokio 异步运行时Rust 生态中最具代表性的异步后端异步编程通信并发编程Serial Studio 贡献指南从报告 Bug 到合入 Pull Request 的完整协作流程Serial Studio 贡献指南从报告 Bug 到合入 Pull Request 的完整协作流程 Serial Studio 是一个开源的遥测数据可视化平桌面应用数据可视化物联网创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考