feat: ci support

[Charliechen114514]

feat: add ci support to promise scripts always usable

[Charliechen114514]

OK， CI测试搞完了，这里是CI测试矩阵和方法总结。截止到评论时变更，策略如下所示

快速参考

场景	触发条件	构建内容	预期时间
改文档	*.md, docs/**	文档检查 + Shell 脚本语法	~1 分钟
改补丁	patches/**	对应组件构建	~5-20 分钟
改脚本	scripts/**	全量构建	~20-30 分钟
改驱动	driver/**	驱动验证	~5 分钟
首次推送	任意	缓存冷，全量构建	~20-30 分钟
后续推送	任意	缓存热，增量构建	~10-15 分钟

---

Workflow 触发规则

1. PR Quick Checks（快速检查）

检查项	触发条件	失败后果
文档覆盖率	改 *.md	⚠️ 警告
脚本语法	改 *.sh	❌ 阻塞合并
配置验证	改 defconfig	❌ 阻塞合并

2. Component Build（组件构建）

组件	触发路径	Timeout	缓存策略
U-Boot	patches/uboot/**, build-uboot.sh	12 分钟	共享 main 缓存
Linux NXP BSP	patches/linux-imx/**, build-linux.sh	25 分钟	共享 main 缓存
Linux Mainline	patches/linux_mainline/**, build-mainline-linux.sh	22 分钟	共享 main 缓存
BusyBox	patches/busybox/**, build-busybox.sh	10 分钟	共享 main 缓存
驱动	driver/**	8 分钟	-

现在从main分支迁出来的实际构建时间可以保证组件编译只需要5分钟左右（并行），所以平均普通非发布PR的CI检查大约在10分钟内可以搞定，如果全量不走ccache大约40分钟

---

并发控制

行为	配置	效果
同 PR 新推送	cancel-in-progress: true	自动取消旧构建
跨 PR	各自独立	并行运行

---

故障排查

问题	可能原因	解决方案
构建被取消	新推送覆盖旧构建	正常行为，等待最新构建
缓存未命中	首次构建 / 工具链变化	正常行为，后续会改善
证书下载失败	网络问题 / CA 证书	Docker 镜像已包含 ca-certificates
超时	构建时间过长	检查代码改动，优化构建

---

提交前自检

# 本地快速验证
./develop/scripts_readme_check.sh    # 文档检查
shellcheck scripts/**/*.sh            # 脚本语法（可选）

# 推送后查看
# GitHub → Actions → 查看运行状态

[Charliechen114514]

@Heizer-Tan ，可以看看这一策略是否存在问题，还要不要补充？补充的话后续五一我继续完善CI