[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 创建流程

  1. 创建特性分支

    git checkout -b feature/your-feature-name
    # 或
    git checkout -b fix/issue-number
    
    1. 进行开发

      • 编写代码
      • 添加测试
        • 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)
        
      • 更新文档
      • 确保代码通过本地测试
  2. 提交代码

    git add .
    git commit -m "[feat] add new feature"
    
  3. 推送到 Fork 仓库

    git push origin feature/your-feature-name
    
  4. 创建 Pull Request

    • 访问 gitcode 仓库页面
    • 点击 "Pull Request" 或"合并请求"
    • 填写 PR 描述(见 PR 创建页面模板)

PR 最佳实践

  1. 保持 PR 小规模
    • 一次 PR 只解决一个问题
    • 便于评审和理解
    • 提高合并效率
    • 建议:单个 PR 不超过 1000 行(含测试)代码变更
  2. 及时更新
    • 定期同步上游主分支
    • 及时响应评审意见
    • 保持 PR 活跃
  3. 清晰描述
    • 详细描述变更原因和方式
    • 提供测试方法
    • 添加截图或示例(如适用)

PR 评审与合入规则

评审要求

  1. 评审人员要求
    • 评审人员必须熟悉相关代码领域
    • 评审人员不能是 PR 作者本人
  2. 评审检查项
    • ✅ 代码质量和风格
    • ✅ 功能正确性
    • ✅ 测试覆盖率(分支 60%,行 80%)
    • ✅ 文档完整性
    • ✅ 性能影响
    • ✅ 安全性
    • ✅ 向后兼容性
  3. CI 检查要求
    • ✅ 所有 CI 检查必须通过
  4. 无 Block 评论
    • PR 不能有任何未解决问题

合入规则

  1. Squash and Merge
    • 将 PR 的所有提交合并为一个提交
    • 保持主分支历史清晰
    • 提交消息使用 PR 标题
  2. 必须满足的条件
    • ✅ 至少 3 位 Maintainer 或 Committer 的 /lgtm,和 1 个 /approve
  3. 禁止的操作
    • ❌ 禁止 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

工作目标和范围

  1. 技术聚焦 围绕基于昇腾服务器单机或集群的昇腾软件自动化部署,提供包括系统组件、 NPU 驱动、CANN 包、MindIE 拉起、故障诊断、MindCluster 集群服务等功能,提升昇腾软件部署的易用性,解决用户部署难、使用难的问题。
  2. 促进协作 通过组织会议、技术分享等方式,促进成员之间的协作和知识共享,提升技术水平。
  3. 最佳实践 在技术实现、接口设计、开发流程等方面推动最佳实践,降低协作成本,提升系统兼容性和可维护性。
  4. 社区建设 通过代码贡献、技术分享等方式,培养技术人才,推动社区生态建设。

例会

  • 周期:每 1 个月举行一次例会,可通过Ascend 开源社区搜索、查看 sig-MindCluster 的会议链接。
  • 申报议题:通过sig-MindCluster Etherpad 链接进入共享文档,编辑申报议题。
  • 参会人员:maintainer、committer、contributor 等核心成员,其他对本 SIG 感兴趣的人员。
  • 会议内容:讨论遗留问题和进展;当期申报的议题;需求评审、任务和优先级;需求规划和进展(roadmap);新晋 maintainer、committer 准入评审。
  • 会议归档:会议纪要位于sig-MindCluster Etherpad 链接

成员列表

SIG 成员列表