文章目录
- 它和你现在做的 CI/CD 有什么关系？
- -1 这个项目的目录
- 2 .github/workflows/(GitHub Actions CI/CD 配置)
- 3 它有哪些 workflow？
- 4 daily_ci.yml 重点是什么？
- 5 python_ci.yml 又是什么？
- -2 SiliconCompiler CI/CD 分层设计
- 为什么要分这么多 CI？
- 每一层是干什么的？
- python_ci.yml（快速 CI）
- daily_ci.yml（每日 CI）
- docker_image.yml（环境构建）
- tools_ci.yml（工具验证）
- lint.yml（代码规范）
- wheels.yml（发布）
- -3 SiliconCompiler CI 分为两类：
- 1. 快速 CI（每次提交）
- 2. 慢速 CI（定时）
SiliconCompiler 是一个开源的模块化硬件构建系统。
SiliconCompiler = 用 Python 统一调度各种 EDA 工具，把芯片/硬件设计流程自动化的开源框架。
它和你现在做的 CI/CD 有什么关系？
我现在做的Gitee Go Demo是：
提交代码 → 运行 Python 脚本 → 上传制品 → 发布SiliconCompiler 做的是更复杂的：
提交硬件/EDA代码 → 安装依赖 → 多系统、多 Python 版本测试 → 调用 EDA/仿真工具 → 跑测试集 → 跑设计案例 → 保存日志、覆盖率、artifact-1 这个项目的目录
siliconcompiler/ 项目核心源码 tests/ 自动化测试代码 examples/ 示例设计/示例项目 docs/ 文档 .github/workflows/ GitHub Actions CI/CD 配置 pyproject.toml Python 项目配置2 .github/workflows/(GitHub Actions CI/CD 配置)
3 它有哪些 workflow？
SiliconCompiler 不是只有一条 CI，而是把不同目的拆成多条 workflow：快速测试、每日测试、工具测试、镜像构建、代码检查、发布构建。
4 daily_ci.yml 重点是什么？
这个 daily_ci.yml 名字叫 Daily CI Tests。它有三种触发方式：手动触发、被其他 workflow 调用、定时触发；定时规则是每天运行一次。
它的结构如下：
Daily CI Tests ├── docker_image │ └── 准备工具容器 ├── cache │ └── 安装依赖、生成缓存、上传 artifact ├── daily_tests_job │ └── 多 Python 版本运行完整测试 └── gallery └── 跑设计样例/benchmark优点：
5 python_ci.yml 又是什么？
python_ci.yml 更像普通项目里的基础 CI。它在 push 到 main 或 test/** 分支、Pull Request、手动触发时运行。它会在多个 Python 版本和多个操作系统上测试，包括 Ubuntu、Windows、macOS，并运行 pytest。
python_ci.yml = 快速基础验证 daily_ci.yml = 每日完整验证-2 SiliconCompiler CI/CD 分层设计
SiliconCompiler 的 CI 不是一条流水线，而是：
CI/CD 体系（多层） ├── 快速 CI（python_ci.yml） ├── 每日 CI（daily_ci.yml） ├── 工具链 CI（tools_ci.yml） ├── 环境构建（docker_image.yml） ├── 代码规范（lint.yml） └── 发布 CI（wheels.yml）不同目的 → 不同 workflow
为什么要分这么多 CI？
我现在的 Demo 是：
一条流水线 → 做所有事每一层是干什么的？
python_ci.yml（快速 CI）
每次提交 / PR → 快速验证daily_ci.yml（每日 CI）
每天跑一次“完整验证”
不是每次提交都跑
docker_image.yml（环境构建）
构建运行环境（工具链）很重要因为：EDA / 算法 → 依赖复杂环境
tools_ci.yml（工具验证）
验证工具是否正常lint.yml（代码规范）
检查代码风格wheels.yml（发布）
打包 + 发布 Python 包-3 SiliconCompiler CI 分为两类：
1. 快速 CI（每次提交）
python_ci.yml快速反馈
2. 慢速 CI（定时）
daily_ci.yml深度验证
