HarmonyOS 7 / API 26 DevEco CLI 接入 CI 前怎么查：构建入口、版本锁定和失败报告怎么做

HarmonyOS 7 / API 26 DevEco CLI 接入 CI 前怎么查构建入口、版本锁定和失败报告怎么做HarmonyOS 7 相关资料里DevEco Code 和 DevEco CLI 已经不只是“本地开发工具”的概念了。它们更适合放进工程流程里看代码怎么创建怎么检查怎么构建怎么把失败信息交给团队处理。我自己更关心的是下面这个场景本地 DevEco Studio 点运行没问题但一放到 CI 或另一台电脑上就开始出现“构建命令找不到、版本不一致、配置文件缺失、失败日志看不出原因”这些问题。这种问题不能等到上线前再排。更稳的做法是先给工程加一道很轻的自检闸口不真正打包、不上传、不改线上配置只检查几个最容易被忽略的入口。先说这篇解决什么这篇只处理一个问题HarmonyOS 7 / API 26 项目准备接 DevEco CLI 或自动化构建前怎么先确认工程具备可重复构建的基本条件。我会拆成两组例子例子一一个“看起来能跑”的工程为什么放到 CI 里不稳例子二把 CLI 版本、构建脚本、检查脚本和 build-profile 补齐后怎么让失败信息变得可读。这里不把 DevEco CLI 写成万能工具。CLI 能做的是把流程固定下来真正决定稳定性的还是工程里有没有清楚的入口和可复查的配置。为什么 HarmonyOS 7 项目更应该重视这个HarmonyOS 7 的开发体验在往工具链和智能辅助方向升级。对单人开发来说本地工具变强是效率提升对团队开发来说真正的价值是让同一套检查可以在不同机器、不同分支、不同环境里重复执行。如果工程里没有固定入口问题会很快变成这样问题本地开发时的表现CI 里的表现CLI 版本没锁本机刚好能跑另一台机器装了新版本行为变了build 脚本没写开发者手动点按钮CI 不知道该执行哪条命令build-profile 缺失IDE 缓存里还能记住配置干净环境直接找不到 product/buildModelint/check 没有入口小问题混进代码到构建后半段才爆定位成本高所以我会把“能不能构建”拆成两层第一层工程是不是具备自动化检查入口第二层真实 DevEco CLI 构建命令再接进去。第一层很轻但能提前拦掉一批低级问题。例子一工程看着有 build其实还不够先准备一个不完整工程。它只有 build 脚本没有声明 DevEco CLI也没有 build-profile。{scripts:{build:echo build}}这种工程在本地可能不会立刻暴露问题因为开发者习惯点 IDE 里的运行按钮。但换到 CI 后脚本只能看到仓库里的文件它不知道你本机 IDE 缓存过什么。我写了一个很小的检查脚本先检查五件事importfsfromnode:fs;importpathfromnode:path;constrootprocess.argv[2]?path.resolve(process.argv[2]):process.cwd();constchecks[];functionreadJson(rel){constfullpath.join(root,rel);if(!fs.existsSync(full))returnnull;try{returnJSON.parse(fs.readFileSync(full,utf8).replace(/^\uFEFF/,));}catch{returnnull;}}functionaddCheck(name,ok,detail,fix){checks.push({name,ok,detail,fix});}constpackageJsonreadJson(package.json);constbuildProfilereadJson(build-profile.json5)||readJson(build-profile.json);addCheck(package.json 可解析,!!packageJson,packageJson?已读取 npm 脚本和依赖声明:没有找到 package.json,补齐 package.json);addCheck(DevEco CLI 入口明确,!!packageJson?.devDependencies?.[deveco/deveco-cli],packageJson?.devDependencies?.[deveco/deveco-cli]||未声明,固定 deveco/deveco-cli 版本);addCheck(构建脚本可被 CI 调用,!!packageJson?.scripts?.build,packageJson?.scripts?.build||未声明 build 脚本,增加 build 脚本);addCheck(质量检查脚本存在,!!packageJson?.scripts?.lint||!!packageJson?.scripts?.check,packageJson?.scripts?.lint||packageJson?.scripts?.check||未声明 lint/check,增加 lint 或 check 脚本);addCheck(HarmonyOS 构建配置存在,!!buildProfile,buildProfile?已找到 build-profile 配置:没有找到 build-profile,补齐 build-profile 配置);跑这个坏样例输出会直接告诉我失败在哪nodework/harmonyos7_deveco_cli_ci_guard.mjs work/tmp-harmonyos7-ci-bad结果里有 3 个失败项{passed:false,failedCount:3,checks:[{name:DevEco CLI 入口明确,ok:false,detail:未声明},{name:质量检查脚本存在,ok:false,detail:未声明 lint/check},{name:HarmonyOS 构建配置存在,ok:false,detail:没有找到 build-profile.json5/build-profile.json}]}这个输出比“构建失败”四个字有用。因为它把修复动作也带出来了先补 CLI 版本再补检查脚本再补 build-profile。例子二把入口补齐后CI 才有稳定抓手再看一个补齐后的样例{devDependencies:{deveco/deveco-cli:1.2.1},scripts:{build:deveco build,lint:deveco check}}再配一个最小的 build-profile{app:{products:[{name:default}]}}再跑同一个检查nodework/harmonyos7_deveco_cli_ci_guard.mjs work/tmp-harmonyos7-ci-good这次结果是通过{passed:true,failedCount:0,checks:[{name:DevEco CLI 入口明确,ok:true,detail:1.2.1},{name:构建脚本可被 CI 调用,ok:true,detail:deveco build},{name:质量检查脚本存在,ok:true,detail:deveco check}]}这里我还查了一下 npm 包信息当前能查到deveco/deveco-cli的 latest 是1.2.1stable 是1.2.0-stable。文章里不建议所有项目盲目跟 latest团队更应该锁定一个验证过的版本。npm.cmd view deveco/deveco-cli name version dist-tags--json我会怎么接到真实工程里如果是一个准备适配 HarmonyOS 7 / API 26 的项目我不会一上来就把 CI 脚本写得很复杂。第一版只保留三个阶段阶段目标失败时应该看到什么precheck检查工程入口哪个配置缺了怎么补check做语法、配置、轻量规则检查哪类代码或配置不符合约定build执行 DevEco CLI 构建哪个 product、buildMode、模块失败也就是说CI 不是只跑一条build命令而是先跑一个更便宜的检查{scripts:{precheck:node scripts/harmonyos-ci-guard.mjs,check:deveco check,build:deveco build}}这样做有两个好处。第一失败更早。比如 build-profile 缺了不需要等完整构建开始以后才报错。第二失败更清楚。CI 日志里能看到“DevEco CLI 没固定版本”或者“缺少 check 脚本”而不是一堆很长的构建输出。两种方案怎么选我试过把所有检查都塞进一条构建命令里但后面维护起来会比较累。更推荐把检查拆开方案做法适合情况问题只跑 buildCI 直接执行构建小 Demo、个人验证失败太晚日志不够直观precheck check build先查入口再做质量检查最后构建团队项目、活动参赛项目、上架前项目初期多写一个脚本我的选择是第二种。多写一个脚本不麻烦但它能把很多“环境问题”提前暴露出来。后面还能继续封装什么这类脚本不应该只检查 package.json。等第一版跑稳后可以继续加这些检查检查 compileSdkVersion、compatibleSdkVersion 是否符合当前目标版本检查 module.json5 里的权限是否和隐私说明一致检查构建产物目录是否存在检查关键截图、隐私协议、上架说明材料是否齐全检查是否有人把本地路径、临时文件、测试地址提交进工程。这些都不属于炫技但很实用。HarmonyOS 7 / API 26 项目越往后走越需要把“本机能跑”升级成“干净环境也能跑、失败原因也说得清”。最后留一个检查清单我会把 DevEco CLI 接入前的最低要求收成这 6 条CLI 版本要锁定不要让每个人机器上跑出不同结果package.json 里必须有统一 build 入口check 或 lint 入口要先于 build 执行build-profile 要进仓库不能只靠 IDE 缓存CI 日志要输出明确失败项不要只给一个失败码升级 HarmonyOS 7 / API 26 前先跑轻量自检再跑真实构建。这样做不是为了把流程搞复杂而是为了让问题早一点出现、清楚一点出现。对 HarmonyOS 项目来说工具链升级越频繁这个基础闸口越值得保留。