Unlucky-Launcher

421 Commits 3 Branches 4 Tags

2 Commits

Include renames

Author	SHA1	Message	Date
AskaEth	5597a4cc18	feat(release,docs): M149 发布构建烘入微软登录 id（仓库 Secret），文档改为「官方构建开箱即用」构建侧：release-build.yml 声明 on.workflow_call.secrets.ULL_MSA_CLIENT_ID（required: false）， cargo build 步以 env 注入它，option_env! 把它烘进二进制；release.yml 的 build job 按名显式透传（与 PUBLISH_TOKEN 同一模式，不用 inherit）。真值放仓库 Secret，不进任何 git 文件；Secret 未录入或 Actions 之外求值为空串时，client_id.rs 的 blank_env_value_counts_as_missing 保证「空白=没配」，不会拿空 id 去联网。文档：README 两版 / help.rs 的 accounts topic / packaging/release-notes.md / packaging/docs/build-and-ci.md 统一成「官方构建已内置登录所需配置、开箱即用，仍可用环境变量 ULL_MSA_CLIENT_ID 覆盖；自建想自带就构建时注入」的功能性口径 —— 不出现 id 本身，也不出现归属描述。 client_id.rs 的模块注释与测试注释同步（原文写「id 不进仓库（用户定案）」，已随 Secret 方案改写），并记下「别把 ULL_MSA_CLIENT_ID 导出到跑 cargo test 的 shell」——presenter 的 M132 入口锚会在已烘焙 id 的构建里故意红。实测：ULL_MSA_CLIENT_ID=<id> cargo build --bin ull 后，清空 env 跑 ull accounts add msa 打出用户码与链接（无「未配置」提示）；同二进制设一个假 env id 则 AADSTS700016 点名该假 id（env 覆盖生效）。单测：core auth 28、unlucky-cli 全套、i18n 30、presenter 222 全绿；M132 锚在烘焙构建里按设计红、在不带 id 的构建里绿。cargo fmt --all --check 通过。	2026-11-06 21:08:53 +08:00
AskaEth	e3ee404bd5	ci(release): M145 把 release.yml 拆成编排 + 两个可复用工作流 release.yml 已是 400 行整，下一处改动必撞全仓行数红线（guards.yml 的 file-size）。拆成「触发 + 槽位表 + 编排」的主工作流与两份 `workflow_call`： - release-build.yml：原 build job 的 11 个步骤逐字搬过去，只有四个矩阵键换成同名 inputs（slot / os / build_dir / rustflags）；矩阵仍由调用方 plan 生成并展开。 - release-publish.yml：原 release job 的 6 个步骤逐字搬过去（PUBLISH_SLOTS 白名单、裁剪、重算 SHA256SUMS、渲染说明、create/edit 幂等）；调用方只留 needs / tag 门禁 / contents: write 的授予，token 走显式透传的 secret，pre-release 三态改读 github.event.inputs.prerelease（dispatch 的 boolean 输入无法表达「空值」）。 on / env / 顶层 permissions / concurrency 与 plan 的槽位表一字未动。校验：YAML 可解析、actionlint 全仓零告警、12 段 run 脚本全部 bash -n 通过、逐步骤比对（归一化后）与拆分前完全相同；120 / 233 / 151 行。	2026-11-06 19:29:47 +08:00

Author

SHA1

Message

Date

AskaEth

5597a4cc18

feat(release,docs): M149 发布构建烘入微软登录 id（仓库 Secret），文档改为「官方构建开箱即用」

构建侧：release-build.yml 声明 on.workflow_call.secrets.ULL_MSA_CLIENT_ID（required: false），
cargo build 步以 env 注入它，option_env! 把它烘进二进制；release.yml 的 build job 按名显式透传
（与 PUBLISH_TOKEN 同一模式，不用 inherit）。真值放仓库 Secret，不进任何 git 文件；Secret 未录入
或 Actions 之外求值为空串时，client_id.rs 的 blank_env_value_counts_as_missing 保证「空白=没配」，
不会拿空 id 去联网。

文档：README 两版 / help.rs 的 accounts topic / packaging/release-notes.md /
packaging/docs/build-and-ci.md 统一成「官方构建已内置登录所需配置、开箱即用，仍可用环境变量
ULL_MSA_CLIENT_ID 覆盖；自建想自带就构建时注入」的功能性口径 —— 不出现 id 本身，也不出现归属描述。
client_id.rs 的模块注释与测试注释同步（原文写「id 不进仓库（用户定案）」，已随 Secret 方案改写），
并记下「别把 ULL_MSA_CLIENT_ID 导出到跑 cargo test 的 shell」——presenter 的 M132 入口锚会在
已烘焙 id 的构建里故意红。

实测：ULL_MSA_CLIENT_ID=<id> cargo build --bin ull 后，清空 env 跑 ull accounts add msa 打出
用户码与链接（无「未配置」提示）；同二进制设一个假 env id 则 AADSTS700016 点名该假 id（env 覆盖生效）。
单测：core auth 28、unlucky-cli 全套、i18n 30、presenter 222 全绿；M132 锚在烘焙构建里按设计红、
在不带 id 的构建里绿。cargo fmt --all --check 通过。

2026-11-06 21:08:53 +08:00

AskaEth

e3ee404bd5

ci(release): M145 把 release.yml 拆成编排 + 两个可复用工作流

release.yml 已是 400 行整，下一处改动必撞全仓行数红线（guards.yml 的 file-size）。
拆成「触发 + 槽位表 + 编排」的主工作流与两份 `workflow_call`：

- release-build.yml：原 build job 的 11 个步骤逐字搬过去，只有四个矩阵键换成同名
  inputs（slot / os / build_dir / rustflags）；矩阵仍由调用方 plan 生成并展开。
- release-publish.yml：原 release job 的 6 个步骤逐字搬过去（PUBLISH_SLOTS 白名单、
  裁剪、重算 SHA256SUMS、渲染说明、create/edit 幂等）；调用方只留 needs / tag 门禁 /
  contents: write 的授予，token 走显式透传的 secret，pre-release 三态改读
  github.event.inputs.prerelease（dispatch 的 boolean 输入无法表达「空值」）。

on / env / 顶层 permissions / concurrency 与 plan 的槽位表一字未动。
校验：YAML 可解析、actionlint 全仓零告警、12 段 run 脚本全部 bash -n 通过、
逐步骤比对（归一化后）与拆分前完全相同；120 / 233 / 151 行。

2026-11-06 19:29:47 +08:00