[TOC]
开发 Ascend-Deployer
请先阅读文档:
代码提交规范
Commit 消息格式
所有提交必须遵循以下格式:
<type> <subject>
<body>
Type(类型)
- feat: 新功能
- fix: Bug修复
- docs: 文档更新
- style: 代码格式(不影响功能,如空格、格式化等)
- refactor: 重构(既不是 Bug 修复也不是新功能)
- perf: 性能优化
- test: 测试相关
- chore: 构建/工具变更(如依赖更新、构建配置等)
- ci: CI/CD 相关变更
Subject(主题)
- 使用祈使句,首字母小写
- 不超过 50 个字符
- 不以句号结尾
- 描述"做了什么"而不是"做了什么改动"
Body(正文,可选)
- 详细描述变更的原因和方式
- 说明与之前行为的对比
- 可以多行,每行不超过 72 个字符
PullRequest
PR 创建流程
-
创建特性分支
git checkout -b feature/your-feature-name # 或 git checkout -b fix/issue-number-
进行开发
- 编写代码
- 添加测试
- Python测试:建议使用unittest框架编写测试用例
#!/usr/bin/env python3 import unittest from unittest.mock import patch, MagicMock from library_test.base_test import BaseLibraryTest class TestCheckUtils(BaseTestCheckUtil): @patch('os.stat') @patch('os.path.isdir') def test_check_cann_install_path_permission(self, mock_isdir, mock_stat): mock_isdir.return_value = False self.cann_check.check_cann_install_path_permission() self.assertEqual([], self.cann_check.error_messages) mock_isdir.return_value = True magic_mock = MagicMock() magic_mock.st_uid = 1 mock_stat.return_value = magic_mock self.cann_check.check_cann_install_path_permission() self.assertEqual(["[ASCEND][ERROR] The owner of the cann installation dir " "'/usr/local/Ascend' must be root, change the owner to root"], self.cann_check.error_messages) self.cann_check.error_messages = [] mock_isdir.return_value = True magic_mock = MagicMock() magic_mock.st_uid = 0 magic_mock.st_mode = 16871 mock_stat.return_value = magic_mock self.cann_check.check_cann_install_path_permission() self.assertEqual(["[ASCEND][ERROR] When installing cann, the user and group of the installation path " "must be root, and the permission must be 755. "], self.cann_check.error_messages) self.cann_check.error_messages = [] mock_isdir.return_value = True magic_mock = MagicMock() magic_mock.st_uid = 0 magic_mock.st_mode = 16877 mock_stat.return_value = magic_mock self.cann_check.check_cann_install_path_permission() self.assertEqual([], self.cann_check.error_messages) - 更新文档
- 确保代码通过本地测试
-
-
提交代码
git add . git commit -m "[feat] add new feature" -
推送到 Fork 仓库
git push origin feature/your-feature-name -
创建 Pull Request
- 访问 gitcode 仓库页面
- 点击 "Pull Request" 或"合并请求"
- 填写 PR 描述(见 PR 创建页面模板)
PR 最佳实践
- 保持 PR 小规模
- 一次 PR 只解决一个问题
- 便于评审和理解
- 提高合并效率
- 建议:单个 PR 不超过 1000 行(含测试)代码变更
- 及时更新
- 定期同步上游主分支
- 及时响应评审意见
- 保持 PR 活跃
- 清晰描述
- 详细描述变更原因和方式
- 提供测试方法
- 添加截图或示例(如适用)
PR 评审与合入规则
评审要求
- 评审人员要求
- 评审人员必须熟悉相关代码领域
- 评审人员不能是 PR 作者本人
- 评审检查项
- ✅ 代码质量和风格
- ✅ 功能正确性
- ✅ 测试覆盖率(分支 60%,行 80%)
- ✅ 文档完整性
- ✅ 性能影响
- ✅ 安全性
- ✅ 向后兼容性
- CI 检查要求
- ✅ 所有 CI 检查必须通过
- 无 Block 评论
- PR 不能有任何未解决问题
合入规则
- Squash and Merge
- 将 PR 的所有提交合并为一个提交
- 保持主分支历史清晰
- 提交消息使用 PR 标题
- 必须满足的条件
- ✅ 至少 3 位 Maintainer 或 Committer 的 /lgtm,和 1 个 /approve
- 禁止的操作
- ❌ 禁止 Force Push 到主分支
- ❌ 禁止合并自己的 PR(必须有他人评审)
合并权限
- Maintainer:可以合并任何 PR
- Committer:可以合并任何 PR
- Contributor:无合并权限,需要等待 Maintainer 或 Committer 合并
CI 说明
CI 检查项目有:
- 执行 Shell:CI 内部调用。
- 执行 Shell:CI 内部调用。
- code_check:编码风格、规范、安全检查。
- sca:开源合规检查。
- anti_poison:病毒扫描。
- build: 构建项目项目软件包
任意一项失败可以通过详情链接查看具体问题。如果是 CI 自身故障,请联系committer,或通过评论 rebuild 尝试重新构建。
Special Interest Group
工作目标和范围
- 技术聚焦 围绕基于昇腾服务器单机或集群的昇腾软件自动化部署,提供包括系统组件、 NPU 驱动、CANN 包、MindIE 拉起、故障诊断、MindCluster 集群服务等功能,提升昇腾软件部署的易用性,解决用户部署难、使用难的问题。
- 促进协作 通过组织会议、技术分享等方式,促进成员之间的协作和知识共享,提升技术水平。
- 最佳实践 在技术实现、接口设计、开发流程等方面推动最佳实践,降低协作成本,提升系统兼容性和可维护性。
- 社区建设 通过代码贡献、技术分享等方式,培养技术人才,推动社区生态建设。
例会
- 周期:每 1 个月举行一次例会,可通过Ascend 开源社区搜索、查看 sig-MindCluster 的会议链接。
- 申报议题:通过sig-MindCluster Etherpad 链接进入共享文档,编辑申报议题。
- 参会人员:maintainer、committer、contributor 等核心成员,其他对本 SIG 感兴趣的人员。
- 会议内容:讨论遗留问题和进展;当期申报的议题;需求评审、任务和优先级;需求规划和进展(roadmap);新晋 maintainer、committer 准入评审。
- 会议归档:会议纪要位于sig-MindCluster Etherpad 链接。