chore(deps): bump actions/upload-artifact from 4 to 7 - #371
Merged
ceilf6 merged 3 commits intoAug 2, 2026
Conversation
Bumps [actions/upload-artifact](https://github.com/actions/upload-artifact) from 4 to 7. - [Release notes](https://github.com/actions/upload-artifact/releases) - [Commits](actions/upload-artifact@v4...v7) --- updated-dependencies: - dependency-name: actions/upload-artifact dependency-version: '7' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
dependabot
Bot
added
dependencies
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
代码评审报告: chore(deps): bump actions/upload-artifact from 4 to 7
风险等级: 中
处理建议: 评论
决策摘要: 单行 action major bump 本身合理且运行环境满足 v6+ 的 Node 24 要求，但同一 workflow 里 download-artifact 仍停留在 v4，且这条 upload→download 配对只在 tag 推送时才被执行，PR CI 无法覆盖，建议合并前明确验证或与 download-artifact 一起升级。
级联分析
- 变更符号:
.github/workflows/release.ymlbuildjob 的Upload zip artifactstep（actions/upload-artifact@v4→@v7） - 受影响流程: 版本 tag 发布链路
build（3 个 OS 矩阵产出 zip）→publish（actions/download-artifact@v4汇总 →softprops/action-gh-release@v2附加到 Release）；以及 PR/workflow_dispatch 的 artifact-only 构建路径 - 变更集外调用方: 仓库内
upload-artifact仅此一处（text search，.github/**全量 grep 仅命中 release.yml:58）；唯一的下游消费者是同文件 release.yml:74 的download-artifact@v4；其余 workflow（ci/repo-guard/gitguardian/contract-guard/update-npm-downloads）均未使用 artifact actions - 置信度: medium — diff 只有一行且我读取了整个 workflow 文件确认了全部消费者；PR 描述中的 #797/#796/#795/#764/#762/#754/#745 是 dependabot 引用的 上游 actions/upload-artifact 仓库 的编号，在本仓库 404 属预期，不代表本仓库产品意图缺失，因此没有降到 degraded；但 upload v7 与 download v4 的实际互操作没有本仓库的执行证据
问题发现
-
[中] 同一 workflow 内 upload/download artifact 版本出现代际差，且配对路径不被 PR CI 覆盖
- 证据: release.yml:58 升到
upload-artifact@v7，release.yml:74 仍为download-artifact@v4。publishjob 由 release.yml:68 的if: startsWith(github.ref, 'refs/tags/')门控，而本 PR 触发的是pull_request（release.yml:15-20 的 paths 命中.github/workflows/release.yml），因此 PR 上只会跑build（upload 生效），download-artifact分支不会执行。 - 受影响调用方/流程: 版本 tag 发布链路的
publishjob；若 v7 上传产物无法被 v4 下载器取回，dist-zips/*.zip为空会直接导致 Release 缺少全部平台资产，且故障首次暴露点是真实发版 tag，而非 PR。 - 最小可行修复: 保持默认打包行为（不要设置 v7 新增的
archive: false，否则name参数被忽略、产物形态改变，desktop-${{ matrix.os }}命名与merge-multiple: true的假设都会失效），并在合并前二选一：把download-artifact一并升到 v6/v7 使上下游同代，或在 fork/预发 tag 上跑一次完整push tag流程确认 zip 能被附加到 Release。
- 证据: release.yml:58 升到
-
[低] Node 24 运行时要求已满足，无需额外动作（信息性）
- 证据: v6.0.0 起
runs.using: node24，要求 runner ≥ 2.327.1。release.yml:32 的矩阵为ubuntu-latest / macos-latest / windows-latest，均为 GitHub 托管 runner。仓库内唯一可能指向自托管的runs-on是 repo-guard.yml:52 的${{ vars.REPO_GUARD_RUNNER || 'ubuntu-latest' }}，而该 workflow 不使用 artifact actions。 - 受影响调用方/流程: 无。
- 最小可行修复: 无需修改；仅在未来把 release 构建迁到自托管 runner 时需要复核 runner 版本。
- 证据: v6.0.0 起
行级发现
- [.github/workflows/release.yml:58] upload 升到 v7 后与本文件 line 74 的
download-artifact@v4形成代际差，而该配对只在 tag 推送时执行、PR CI 覆盖不到；最小修复是同步升级 download-artifact 或在合并前用一次预发 tag 验证 Release 资产完整，并保持 v7 的archive为默认值以免name参数失效。
Karpathy 评审
- 假设: 隐含假设「v7 上传的产物可被 v4 下载器取回」。v4 起 artifact 后端 API 未变、v7 默认仍是打包上传，因此大概率成立，但本仓库无执行证据（inferred）。另一隐含假设是 runner 支持 Node 24，这一条已由托管 runner 确认成立。
- 简洁性: 单行版本号变更，无新增抽象、无配置膨胀，
with块的name/path/if-no-files-found: error在 v7 中均保留，跨 3 个 major 无参数改名或废弃。 - 结构质量: 无退化。文件仍为 83 行，job 边界与
build/publish拆分不受影响；action 版本引用方式（major tag）与仓库既有约定一致（checkout@v6、setup-node@v6、pnpm/action-setup@v6）。 - 变更范围: 严格最小 diff，+1/-1，无夹带重构或格式噪声。
- 验证: PR 触发会真实执行 upload 步骤，
if-no-files-found: error提供了上传侧的硬失败保障；缺口在下载侧——publishjob 的 tag 门控使 upload/download 配对无法在本 PR 上被证明。
缺失覆盖
- upload v7 → download v4 的端到端配对：目前无任何自动化路径覆盖。合并前建议在 fork 或临时预发 tag 上跑一次完整
push tag流程，确认三个desktop-<os>zip 被merge-multiple: true正确聚合并附加到 Release。 - 若倾向于让该风险长期可测，可考虑后续单独 PR 把
publish的下载步骤纳入非 tag 的可验证路径（例如 workflow_dispatch 下的 dry-run），但这超出本 PR 范围，不应在此处扩大改动。
|
|
||
| - name: Upload zip artifact | ||
| uses: actions/upload-artifact@v4 | ||
| uses: actions/upload-artifact@v7 |
There was a problem hiding this comment.
upload 升到 v7 后与本文件 line 74 的 download-artifact@v4 形成代际差，而该配对只在 tag 推送时执行、PR CI 覆盖不到；最小修复是同步升级 download-artifact 或在合并前用一次预发 tag 验证 Release 资产完整，并保持 v7 的 archive 为默认值以免 name 参数失效。
This was referenced Aug 2, 2026
There was a problem hiding this comment.
代码评审报告: chore(deps): bump actions/upload-artifact from 4 to 7
风险等级: 低
处理建议: 评论
决策摘要: 可以合并——单行 action 大版本 bump，运行环境（GitHub 托管 runner）满足 v6+ 的 Node 24 / runner 2.327.1 要求，默认参数行为不变；唯一剩余风险是 upload@v7 与仍停留在 v4 的 download-artifact 的配对只在打 tag 时才被真实执行，PR CI 覆盖不到。
级联分析
- 变更符号:
.github/workflows/release.ymlbuild job 的Upload zip artifactstep，actions/upload-artifact由v4升至v7。 - 受影响流程: tag
v*的 release 流程（build 矩阵 → publish 附加资产）；以及pull_request/workflow_dispatch触发的仅产物构建路径。 - 变更集外调用方:
.github/workflows/release.yml:74的actions/download-artifact@v4（merge-multiple: true，消费本 step 产出的desktop-${{ matrix.os }}三个 artifact）。全仓.github/文本搜索确认这是唯一消费者，且upload-artifact在本仓仅此一处使用 (text search)。 - 置信度: medium — 无代码图谱，结论基于全量 workflow 文本搜索与 PR 正文引用的上游 release notes；受影响消费者（download-artifact）未在本变更集内同步升级。PR 正文中被解析为“关联 issue”的 #745–#797 全部是 actions/upload-artifact 上游仓库的 PR 编号，不是本仓 issue，其 404 不构成本仓产品意图缺失，因此未据此降级到 degraded。
问题发现
-
[低] upload 升至 v7 而配对的 download 仍为 v4，且该组合不被 PR CI 验证
- 证据:
.github/workflows/release.yml:58升级为upload-artifact@v7，.github/workflows/release.yml:74仍为download-artifact@v4。publish job 有if: startsWith(github.ref, 'refs/tags/')（release.yml:68），因此本 PR 触发的 workflow 只跑 build+upload，不跑 download 与 release 附件。 - 受影响调用方/流程: tag 发布流程的
Download all platform zips→softprops/action-gh-release。upload v5/v6/v7 的 release notes 记录的破坏性变更是 Node 运行时（20→24）、打包为 ESM、新增archive直传选项，未提到 Artifacts 服务端 API 版本变化，因此 v7↔v4 的跨版本下载预期仍可用 (inferred，依据 PR 正文 release notes，非实测)。 - 最小可行修复: 合并前或合并后、下次正式 tag 前，用一个预发布 tag（或临时把 publish job 的 ref 条件放宽跑一次）验证一次完整 round trip；或与 dependabot 的 download-artifact 升级 PR 一并合入，保持两端版本对齐。
- 证据:
-
[低] runner 与参数兼容性已核对，无阻塞项
- 证据: build job 使用
runs-on: ${{ matrix.os }}，矩阵为ubuntu-latest/macos-latest/windows-latest（release.yml:32-33），全部为 GitHub 托管 runner，自动满足 v6 要求的 runner ≥ 2.327.1 与 Node 24；仓库内无 self-hosted runner 用于该 workflow（repo-guard.yml:52的可配置 runner 不使用 upload-artifact）。v7 新增的archive参数默认为true，本 step 未设置该参数，故path: apps/desktop/release/*.zip即使匹配多个文件也仍按旧行为打包，name与if-no-files-found: error语义不变。 - 受影响调用方/流程: 无。
- 最小可行修复: 无需修改。
- 证据: build job 使用
行级发现
- [.github/workflows/release.yml:58] upload 升到 v7，但同一 workflow 第 74 行的
download-artifact仍是 v4，而 publish job 仅在 tag 上运行，本 PR 的 CI 只能验证上传半程；建议与 download-artifact 升级 PR 对齐版本，或在正式发版前用预发布 tag 跑通一次下载与附件流程。
Karpathy 评审
- 假设: 隐含假设 upload v7 产出的 artifact 仍可被 download v4 读取。上游 v5/v6/v7 均为运行时/打包/新增选项类变更，未声明 Artifacts 服务契约变更，该假设合理但未在本仓实测。另一隐含假设是 runner 均为 GitHub 托管——已核对属实。
- 简洁性: 单行版本号变更，无新增抽象、配置或分支，符合最小改动。
- 结构质量: 无结构影响。版本以 major tag 形式引用与仓库既有约定一致（checkout@v6 / setup-node@v6 / download-artifact@v4），未引入不一致。
- 变更范围: 严格外科手术式，1 文件 +1/-1，无格式噪声或顺带清理。
.github/dependabot.yml:27-31的 github-actions 生态未设置 major 忽略规则（仅 npm 生态在第 18-21 行忽略 major），故该 major bump 符合仓库既定策略。 - 验证: PR 的
paths过滤包含.github/workflows/release.yml（release.yml:19），因此本 PR 会在三个 OS 上真实执行 build+upload，if-no-files-found: error使空产物会导致失败——上传半程有真实验证信号。前提是该 workflow run 已成功；我没有 CI 结果数据，未把它当作已通过的证据。下载半程无覆盖。
缺失覆盖
- upload@v7 → download@v4 的完整 round trip 未被任何 PR 触发路径覆盖，仅在 tag 推送时首次真实执行；建议在下一次正式发版前用预发布 tag 验证一次，避免发版当天才发现问题。
- PR 已开启 30 天以上且自动 rebase 已关闭，合并前确认 base 分支
develop上的release.yml未发生其他改动（当前 checkout 中第 58 行上下文与 diff 一致）。
|
|
||
| - name: Upload zip artifact | ||
| uses: actions/upload-artifact@v4 | ||
| uses: actions/upload-artifact@v7 |
There was a problem hiding this comment.
upload 升到 v7，但同一 workflow 第 74 行的 download-artifact 仍是 v4，而 publish job 仅在 tag 上运行，本 PR 的 CI 只能验证上传半程；建议与 download-artifact 升级 PR 对齐版本，或在正式发版前用预发布 tag 跑通一次下载与附件流程。
ceilf6
added a commit
to HaveNiceDa/FrontAgent
that referenced
this pull request
Aug 2, 2026
Contract Guard demands two things dependabot structurally cannot supply: a scripts/tests/ contract test in the same PR whenever a critical file changes, and a structured GitNexus impact summary in the PR body. Its body is generated release notes and it does not touch tests, so every bump that edits .github/workflows/ fails permanently — ceilf6#371, ceilf6#373 and ceilf6#378 have all been red since they opened, on exactly these five lines: - Missing contract test for critical file: .github/workflows/release.yml - Missing GitNexus impact summary field: Risk level (…and the other three fields) A check that can never pass does not add safety; it trains maintainers to skim past the check panel. repo-guard.yml already skips dependabot for the same reason. These bumps remain gated by CODEOWNERS review and by CI, which is the only required status check. Keyed on the PR author rather than github.actor, unlike repo-guard.yml: the moment a maintainer runs update-branch or pushes to a dependabot branch, actor becomes the maintainer and an actor-keyed skip stops applying — which is how this gate came back red on all three PRs while they were being processed. The author field does not move with the pusher. The test pins both halves, and also pins that .github/workflows/ is still classified critical, so the exemption gets revisited if that ever stops being true. Closes ceilf6#443 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
dependabot
Bot
deleted the
dependabot/github_actions/actions/upload-artifact-7
branch
August 2, 2026 12:08
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps actions/upload-artifact from 4 to 7.
Release notes
Sourced from actions/upload-artifact's releases.
... (truncated)
Commits
043fb46Merge pull request #797 from actions/yacaovsnc/update-dependency634250cInclude changes in typespec/ts-http-runtime 0.3.5e454baaReadme: bump all the example versions to v7 (#796)74fad66Update the readme with direct upload details (#795)bbbca2dSupport direct file uploads (#764)589182cUpgrade the module to ESM and bump dependencies (#762)47309c9Merge pull request #754 from actions/Link-/add-proxy-integration-tests02a8460Add proxy integration testb7c566aMerge pull request #745 from actions/upload-artifact-v6-releasee516bc8docs: correct description of Node.js 24 support in READMEYou can trigger a rebase of this PR by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)