## 问题分析与解决 ### 问题根源构建工作流 `build-with-bazel` 在 GitHub Actions 中运行时报错："No files were found with the provided path: release_artifacts/. No artifacts will be uploaded。"经过分析，发现原脚本的构建产物收集逻辑存在缺陷。 ### 原脚本问题 `.github/workflows/build.yml:21-32` 中的构建产物收集脚本使用以下逻辑： ```bash for dir in "$BIN_PATH"/*/ ; do dir_name=$(basename "$dir") zip_file="$dir/${dir_name}.zip" if [ -f "$zip_file" ]; then cp "$zip_file" release_artifacts/ fi done ``` 这个逻辑假设： 1. Bazel 输出目录 (`$BIN_PATH`) 下每个子目录都对应一个数据包 2. 每个数据包的 ZIP 文件命名格式为 `目录名.zip` 但实际构建输出结构是： - `bazel-bin/subprojects/stone-disappearance/stone-disappearance.zip` - `bazel-bin/subprojects/auto-lucky-block/auto-lucky-block.zip` 原脚本在 `$BIN_PATH/subprojects/` 目录下查找 `subprojects.zip`，显然无法找到正确的构建产物。 ### 解决方案将构建产物收集逻辑从目录扫描改为使用 `find` 命令递归查找所有 ZIP 文件： **修改内容** `.github/workflows/build.yml:21-32` ```yaml - name: Prepare artifacts for upload run: | mkdir -p release_artifacts BIN_PATH=$(bazel info bazel-bin) find "$BIN_PATH" -name "*.zip" -exec cp {} release_artifacts/ \; ``` ### 验证测试 1. 使用 `bazel build //subprojects/stone-disappearance` 测试构建成功 2. 验证 `find` 命令能正确找到构建产物：`/home/runner/.cache/bazel/.../bin/subprojects/stone-disappearance/stone-disappearance.zip` 3. 确认修改后的脚本能正确复制所有数据包的 ZIP 文件到 `release_artifacts/` 目录 ### 提交记录已按照项目提交规范创建提交：`6bea609 👷 ci: fix build artifact collection` ### 影响范围 - 修复后，所有数据包的构建产物都能正确收集并上传到 GitHub Actions Artifacts - 不影响现有的发布工作流 (`release.yml`) 和其他 CI/CD 流程 - 提高构建产物收集的可靠性，避免因目录结构变化导致的问题 Closes #132 <a href="https://opencode.ai/s/Sc9Bt5RY"><img width="200" alt="New%20session%20-%202026-01-24T18%3A27%3A14.401Z" src="https://social-cards.sst.dev/opencode-share/TmV3IHNlc3Npb24gLSAyMDI2LTAxLTI0VDE4OjI3OjE0LjQwMVo=.png?model=deepseek/deepseek-reasoner&version=1.1.34&id=Sc9Bt5RY" /></a> [opencode session](https://opencode.ai/s/Sc9Bt5RY)  |  [github run](/TouchController/E1epack/actions/runs/21319590251)

Uh oh!

build工作流找不到构建产物 #132

Description

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions