Eeveid/lightOps
1
0
Fork 1
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix: 修复 Gitea 发布工作流在 fork/镜像仓库中的兼容性问题 #1

Merged
Eeveid merged 24 commits from zhilv/lightOps:main into main 2026-05-28 18:53:16 +08:00
Conversation 0 Commits 24 Files Changed 3 +117 -22
zhilv commented 2026-05-26 20:53:31 +08:00
Contributor
Copy Link

变更内容

本次修复主要围绕 Gitea Actions 发布流程在 fork / 镜像仓库中的兼容性问题展开。

工作流与仓库上下文

  • 检出代码时改为基于当前触发仓库动态克隆，不再硬编码主仓库地址
  • 发布 Release 时根据当前仓库上下文动态计算 owner / repo
  • 调用发布脚本时显式传递 gitea-url、owner、repo，避免脚本回退到默认仓库配置
  • 检出阶段改为按 tag 浅克隆，移除额外的 git fetch --tags --force

Rust 构建与工具链

  • 发布工作流不再依赖 runner 自带的旧版 cargo
  • 改为通过 rustup 安装并使用 stable 工具链，兼容 Cargo.lock v4
  • 为 rustup 配置镜像下载源，避免直连 static.rust-lang.org 超时
  • 为 Cargo 写入 ~/.cargo/config.toml，将 crates.io 切换到 rsproxy sparse registry
  • 当目标等于当前 host target 时走原生构建，避免 cc-rs 误寻找交叉编译器

Release 发布

  • 发布步骤显式使用 RELEASE_TOKEN
  • 发布脚本优先使用 node 处理 JSON，兼容无 python/python3 环境
  • 创建 Release 时使用 main 作为 target_commitish，避免提交 SHA 在当前 Gitea 实例下返回 404
  • 修复发布完成后的链接可能错误指向默认仓库的问题

解决的问题

修复了以下场景下的失败或异常：

  • fork / 镜像仓库打 tag 后仍去主仓库检出代码
  • runner 自带 Rust 工具链版本过旧，无法解析 Cargo.lock v4
  • rustup / Cargo 直连官方源超时导致工具链或依赖下载失败
  • native 构建时错误寻找 x86_64-linux-gnu-gcc
  • Release 创建成功但日志中的仓库链接错误
  • 发布脚本在无 Python 环境下无法运行
## 变更内容 本次修复主要围绕 Gitea Actions 发布流程在 fork / 镜像仓库中的兼容性问题展开。 ### 工作流与仓库上下文 - 检出代码时改为基于当前触发仓库动态克隆，不再硬编码主仓库地址 - 发布 Release 时根据当前仓库上下文动态计算 `owner` / `repo` - 调用发布脚本时显式传递 `gitea-url`、`owner`、`repo`，避免脚本回退到默认仓库配置 - 检出阶段改为按 tag 浅克隆，移除额外的 `git fetch --tags --force` ### Rust 构建与工具链 - 发布工作流不再依赖 runner 自带的旧版 `cargo` - 改为通过 `rustup` 安装并使用 `stable` 工具链，兼容 `Cargo.lock v4` - 为 `rustup` 配置镜像下载源，避免直连 `static.rust-lang.org` 超时 - 为 Cargo 写入 `~/.cargo/config.toml`，将 crates.io 切换到 `rsproxy` sparse registry - 当目标等于当前 host target 时走原生构建，避免 `cc-rs` 误寻找交叉编译器 ### Release 发布 - 发布步骤显式使用 `RELEASE_TOKEN` - 发布脚本优先使用 `node` 处理 JSON，兼容无 `python/python3` 环境 - 创建 Release 时使用 `main` 作为 `target_commitish`，避免提交 SHA 在当前 Gitea 实例下返回 404 - 修复发布完成后的链接可能错误指向默认仓库的问题 ## 解决的问题 修复了以下场景下的失败或异常： - fork / 镜像仓库打 tag 后仍去主仓库检出代码 - runner 自带 Rust 工具链版本过旧，无法解析 `Cargo.lock v4` - `rustup` / Cargo 直连官方源超时导致工具链或依赖下载失败 - native 构建时错误寻找 `x86_64-linux-gnu-gcc` - Release 创建成功但日志中的仓库链接错误 - 发布脚本在无 Python 环境下无法运行
zhilv added 24 commits 2026-05-26 20:53:31 +08:00
🐛 fix(workflow): 修复发布工作流的 Rust 初始化逻辑 121bd8bd7f 
- 在系统依赖阶段补充 rustc 和 cargo，减少对 rustup 在线安装的依赖
- 安装 Rust 前先加载 ~/.cargo/env 并补充 ~/.cargo/bin 到 PATH
- 仅在本机确实缺少 cargo 时才走 rustup 兜底，避免 runner 已装 rustup 但未生效时误触发联网更新
🐛 fix(workflow): 修复发布流程的仓库来源识别 e6f3f50ccb 
- 检出代码时改为根据触发仓库动态拼接克隆地址，去掉对 Eeveid/lightOps 的硬编码
- 使用当前触发仓库拆分 owner 和 repo，确保 Release 发布到正确项目
- 避免在 origin2 等镜像仓库打标签后，工作流仍去主仓库检出代码导致找不到标签
🐛 fix(workflow): 避免发布流程检出阶段卡住 b4001f5e12 
- 检出代码时按标签直接浅克隆，避免 clone 后再次 fetch tags
- 为 git 检出步骤设置 GIT_TERMINAL_PROMPT=0，防止凭证等待导致任务挂起
- 用本地提交校验替代多余的远程访问，降低 runner 在镜像仓库发布时的阻塞风险
🐛 fix(workflow): 修复发布构建的 Rust 目标配置 f839ea2266 
- 安装和构建阶段优先使用系统 rustc/cargo，避免被 ~/.cargo/bin 中的 musl 工具链覆盖
- 仅在系统工具链缺失时才加载或安装 rustup，减少 runner 现有环境带来的干扰
- 当使用 rustup 时自动补齐 x86_64-unknown-linux-gnu target，匹配发布脚本的构建目标
🐛 fix(workflow): 提高 Rust 环境初始化兼容性 9042f8b8a0 
- 用纯 shell 逻辑替换 PATH 过滤中的 awk 写法，避免不同 runner 上的 awk 语法差异
- 保持优先系统工具链、跳过 ~/.cargo/bin 的策略不变
- 修复安装 Rust 步骤在 shell 解析阶段直接失败的问题
🐛 fix(workflow): 避免发布流程在线下载 Rust 目标 4322023820 
- 根据 runner 上已可用的 Rust host target 或已安装 target 选择构建目标
- 去掉 rustup target add，避免网络受限环境在下载 rust-std 时卡住
- 将选中的构建目标写入临时文件并传递给发布打包脚本
🐛 fix(release): 修复原生目标构建时的 C 编译器选择 9b63ef38c3 
- 仅在 x86_64-unknown-linux-gnu 目标已安装且存在 x86_64-linux-gnu-gcc 时才选择 GNU 交叉目标
- 打包脚本在目标等于当前 Rust host target 时改为原生 cargo build，不再显式传 --target
- 避免 cc-rs 在原生构建场景下错误寻找 x86_64-linux-gnu-gcc 导致发布失败
🐛 fix(release): 兼容发布脚本中的 python3 环境 57447882cb 
- 发布脚本优先使用 python3，没有时再回退到 python
- 修复 runner 仅提供 python3 时发布阶段直接失败的问题
- 保持 Release 创建和附件上传逻辑不变
🐛 fix(release): 去除发布脚本对 Python 的硬依赖 100909a47f 
- 发布脚本优先使用 node 处理 JSON，没有 node 时再回退到 python3 或 python
- 修复 runner 缺少 Python 解释器时 Release 创建阶段直接失败的问题
- 保持现有 Gitea API 调用和附件上传流程不变
🐛 fix(release): 兼容不支持 Releases 的仓库 a4f73c20d7 
- 发布脚本在 Gitea Releases API 返回 404 时不再直接失败
- 对未开启 Releases 或 Token 无 Release 权限的仓库改为输出已生成的包路径并跳过上传
- 保持支持 Releases 的仓库仍按原逻辑创建 Release 并上传附件
🐛 fix(workflow): 将发布任务切换为 ubuntu-latest b1d07e604f 
- 将 .gitea/workflows/release.yml 的 runs-on 从 runner_admin 改为 ubuntu-latest
- 便于在新的 fork 仓库中按 act runner 的通用标签方式调度任务
- 保留前面已经修过的动态仓库检出、构建和发布兼容逻辑
🐛 fix(workflow): 回退发布任务到 runner_admin aad3db8315 
- 将 release 工作流的 runs-on 从 ubuntu-latest 调回 runner_admin
- 避免当前 act runner 在 Set up job 阶段卡住，优先验证发布链本身
- 保留前面已经修复的动态检出、Rust 构建和 Release 兼容逻辑
🐛 fix(release): 改用 RELEASE_TOKEN 发布版本 abcfcf7b33 
- 工作流发布步骤改为显式使用仓库密钥 RELEASE_TOKEN
- 去掉发布脚本对 404 的吞错处理，改回明确暴露真实权限或接口错误
- 便于验证当前自定义 token 是否具备 Gitea Release 创建与附件上传权限
🔧 chore(workflow): 增加 Release Token 预检日志 70f80355da 
- 在发布步骤前输出 RELEASE_TOKEN 长度，避免空值或旧值问题继续被误判
- 使用当前 token 预检 /api/v1/user 和 releases 列表接口状态码
- 为后续定位 workflow 与本地手工调用结果不一致的问题提供直接证据
🔧 chore(workflow): 移除 Release Token 预检日志 c47791bc3c 
- 清理发布步骤中的临时调试输出
- 保持使用 RELEASE_TOKEN 进行 Release 发布
- 为重新验证更新后的仓库密钥提供干净日志
🔧 chore(workflow): 打印 Release Token 调试信息 975b7b170c 
- 在发布步骤中直接输出 RELEASE_TOKEN 明文以确认仓库密钥实际注入值
- 同时打印 GITEA/GITHUB/RELEASE 相关环境变量便于比对
- 仅用于当前排障，后续验证完成后应移除
🔧 chore(workflow): 增强调试 Release Token 校验 13e4d1f684 
- 输出当前 RELEASE_TOKEN 的 sha256 摘要，便于与本地成功 token 做无泄露比对
- 在发布前直接用当前 token 探测创建 Release API 并打印响应体
- 为定位 workflow 内 token 与手工 curl 结果不一致的问题提供确定性证据
🐛 fix(release): 用默认分支替代提交 SHA 创建 Release acc89faa8b 
- 发布步骤不再将 git rev-parse HEAD 的完整提交 SHA 作为 target_commitish
- 改为显式使用 main，匹配当前 Gitea 实例对 Release 创建接口的可接受参数
- 清理前面为定位 token 问题加入的临时 probe 调试逻辑
🐛 fix(release): 显式传递发布目标仓库参数 738ff8248f 
- 发布步骤调用 publish-gitea-release.sh 时显式传入 gitea-url、owner 和 repo
- 避免子进程回退到脚本默认值 Eeveid/lightOps，导致日志和 Release 目标仓库混淆
- 保持当前使用 RELEASE_TOKEN 和 main 作为 target_commitish 的逻辑不变
fix: 修改运行环境 8db385cca6
🐛 fix(workflow): 固定使用新版 Rust stable 工具链 f1491ba114 
- 发布工作流不再依赖 runner 自带 rustc/cargo 版本
- 改为通过 rustup 安装并默认切换到 stable 工具链，兼容 Cargo.lock v4
- 构建步骤统一加载 ~/.cargo/env，避免旧版系统 cargo 抢占路径
🐛 fix(workflow): 为 rustup 配置镜像下载源 a79ef99500 
- 在安装 Rust 和构建步骤中设置 RUSTUP_DIST_SERVER 与 RUSTUP_UPDATE_ROOT
- 避免 runner 直连 static.rust-lang.org 超时导致 stable 工具链安装失败
- 保持通过 rustup stable 获取新版 cargo 以兼容 Cargo.lock v4
🐛 fix(workflow): 为 Cargo 配置 crates 镜像源 7e8d4baac6 
- 在安装 Rust 步骤写入 ~/.cargo/config.toml，将 crates-io 切换到 rsproxy sparse registry
- 避免 runner 访问 index.crates.io 超时导致依赖下载失败
- 与 rustup 镜像配置配合，统一走国内镜像完成工具链和依赖安装
🐛 fix(workflow): 修复 Cargo 镜像配置的 YAML 语法 9ffe425d6e 
- 去掉 run 脚本中的 heredoc 写法，避免 YAML 将 TOML 内容误判为工作流字段
- 改为使用 printf 生成 ~/.cargo/config.toml
- 保持 crates-io 切换到 rsproxy sparse registry 的逻辑不变
Eeveid merged commit 2e30661c72 into main 2026-05-28 18:53:16 +08:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Eeveid
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Eeveid/lightOps#1
Delete Branch "zhilv/lightOps:main"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?