包管理器开发工具CLI【免费下载链接】pnpmFast, disk space efficient package manager项目地址https://gitcode.com/gh_mirrors/pn/pnpm点击查看免费下载导读本指南围绕 pnpm 在pnpm outdated与pnpm update中新增的 GitHub Actions 依赖识别能力展开当工作流使用 GitHub 官方 self-repository 语法uses: $/.github/actions/setup引用同仓库内的本地复合 actioncomposite action或可复用工作流时pnpm 会像对待./引用一样递归解析并检查其中锁定的第三方 action 版本。读完本文你将理解$/与./两种本地引用语法的区别、pnpm 的 opt-in 启用机制--include-github-actions与update.githubActions、底层源码实现原理以及可复现的测试验证方式。背景pnpm 如何把 GitHub Actions 当作依赖来管理pnpm 的outdated/update命令不仅能管理 npm 包还能扫描项目.github/workflows目录下的工作流文件把其中uses:字段引用的第三方 action 视为依赖并检查是否有新版本。这一能力封装在 pnpm11/deps/github-actionsTypeScript 实现以及 Rust 版本的 github-actions crate 中。需要注意GitHub Actions 依赖检查是默认关闭的。原因是读取这些依赖需要对每个被引用的仓库执行git ls-remote参见 github_actions.rs 中的注释与opted_in逻辑成本较高因此必须显式开启命令行参数pnpm outdated --include-github-actions或pnpm update --include-github-actions配置文件在.npmrc/pnpm-workspace.yaml中设置update.githubActionstrue# 检查 GitHub Actions 依赖是否过期 pnpm outdated --include-github-actions # 直接更新 GitHub Actions 依赖默认更新到 caret 兼容的最新版 pnpm update --include-github-actions对应的 opt-in 判定逻辑在源码中实现为// pnpm11/deps/github-actions/src/index.ts export function shouldCheckGitHubActions (opts: GitHubActionsOptInOptions): boolean { return opts.includeGithubActions true || opts.updateConfig?.githubActions true }核心新能力识别uses: $/self-repository 本地引用GitHub 的$/语法是什么在 GitHub Actions 中引用当前仓库内部的复合 action 或可复用工作流有两种写法语法含义示例./仓库相对路径旧写法uses: ./.github/actions/setup$/self-repository 语法仓库根锚定uses: $/.github/actions/setup$/是 GitHub 官方提供的仓库自引用语法显式表示从当前仓库根目录解析语义上等价于./但更清晰地表达引用本仓库内的资源这一意图。pnpm 的新改动正是让pnpm outdated和pnpm update在扫描工作流时把$/与./同等对待——两者都会被当作本地引用去解析并继续递归扫描其引用的第三方 action。源码实现一处解析两种前缀在 TypeScript 实现中本地引用的识别集中在parseLocalReference与resolveLocalReference两个函数index.ts/** * Returns the repository-relative path of a uses: value that points into the * same repository, either the workspace-relative ./ form or GitHubs * self-repository $/ form. Returns null for every other value, such as an * owner/reporef or docker:// reference, which is left to * parseActionReference. */ function parseLocalReference (value: string): string | null { return value.startsWith(./) || value.startsWith($/) ? value.slice(2) : null }关键点在于./和$/去掉前缀后剩下的都是仓库根目录下的相对路径例如.github/actions/setup因此解析逻辑可以完全共用。resolveLocalReference随后完成路径解析与安全校验若引用指向.yml/.yaml文件直接使用该文件否则按action.yml/action.yaml的顺序在目标目录下查找对解析结果执行fs.realpath并用isSubdir校验其必须位于项目根目录之内防止路径逃逸对应错误GITHUB_ACTIONS_WORKFLOW_OUTSIDE_ROOT参考 workflow.rs 中 Rust 实现的同等校验。Rust 实现采用完全一致的策略workflow.rsif let Some(local) value .strip_prefix(./) .or_else(|| value.strip_prefix($/)) { if let Some(candidate) resolve_local_reference(root, canonical_root, local).await? { scan.local_references.push(candidate); } continue; }递归跟随本地 action 内部的第三方依赖也能被发现识别出本地引用后pnpm 并不会停在本地 action 这一层而是将其action.yml/action.yaml或可复用工作流文件加入扫描队列继续解析。例如下面这个典型的 monorepo 场景# .github/workflows/ci.yml name: CI on: [push] jobs: test: runs-on: ubuntu-latest steps: - uses: $/.github/actions/setup # 本仓库内的复合 action - uses: actions/checkoutv4.1.0 # 第三方 action会被检查版本# .github/actions/setup/action.yml name: setup runs: using: composite steps: - uses: actions/setup-nodev4.2.0 # 藏在本地 action 里的第三方依赖此时pnpm outdated --include-github-actions会穿透$/.github/actions/setup发现其中的actions/setup-nodev4.2.0并检查其是否有更新版本——这正是 test/index.test.ts 中 follows self-repository references to local composite actions 测试所验证的行为test(follows self-repository references to local composite actions, async () { const dir await fixture({ .github/workflows/ci.yml: jobs: test: steps: - uses: $/.github/actions/setup , .github/actions/setup/action.yml: runs: using: composite steps: - uses: actions/checkoutv4.1.0 , }) // findOutdatedGitHubActions 能返回 actions/checkout 的过期信息 })Rust 侧同样有对应测试tests.rs其中直接构造了uses: $/.github/actions/setup的用例。版本比较策略如何判定过期$/支持只是入口识别的一部分识别出 action 之后pnpm 会对其引用的仓库执行版本发现与语义化比较读取仓库引用对每个 action 仓库执行git ls-remote通过getRepoRefs解析refs/tags/vX.Y.Z形式的标签index.ts确定当前版本findCurrentVersion支持v1.2.3、v1、40 位 commit SHA配合行内注释# v1.2.3等多种引用形式index.ts计算 wanted / latest若当前版本是预发布版则在全部版本中选否则在稳定版本中用^当前版本的 caret 规则选出wanted兼容更新并取最新版作为latest更新写入updateGitHubActions默认更新到wantedcaret 兼容传入latest: true才允许不兼容的大版本更新。写入时总是固定到精确 commit SHA并把对应语义化版本号写入行内注释- uses: actions/checkout9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0如果工作流文件在解析过程中被外部修改源文件片段与记录的原始值不匹配pnpm 会抛出GITHUB_ACTIONS_WORKFLOW_CHANGED错误并提示重试避免并发编辑造成损坏index.ts。实战操作示例下面以一个真实的 monorepo 为例演示完整的检查与更新流程。步骤 1启用检查并查看过期情况pnpm outdated --include-github-actions输出类似字段含义见 index.ts 中的OutdatedGitHubAction接口┌─────────────────────────────────────────┬────────────┬────────┬──────────┐ │ name │ current │ latest │ wanted │ ├─────────────────────────────────────────┼────────────┼────────┼──────────┤ │ actions/checkout │ 4.1.0 │ 5.0.0 │ 4.2.0 │ │ owner/tool (via ./.github/actions/setup)│ 2.0.0 │ 2.1.0 │ 2.1.0 │ └─────────────────────────────────────────┴────────────┴────────┴──────────┘其中wanted是 caret 兼容的最新版latest是最新发布版。若只想看兼容更新可设置compatible: true。步骤 2执行更新# 默认更新到 caret 兼容版本推荐避免破坏性变更 pnpm update --include-github-actions # 允许跨大版本更新 pnpm update --include-github-actions --latest更新会以精确 commit SHA 版本注释的形式直接改写.github/workflows/*.yml并自动跟随$//./引用的本地复合 action。步骤 3选择性更新按名称过滤与 npm 包一样可以用 selector 过滤要更新的 action例如pnpm update --include-github-actions actions/checkout内部通过isGitHubActionSelector区分 action selector 与 npm 包 selector含/且不以开头视为 action并用normalizeGitHubActionSelector去掉ref后缀做匹配index.ts。实现细节与注意事项服务器地址action 的 git 地址与 homepage 默认使用GITHUB_SERVER_URL环境变量未设置时回退到https://github.com支持 GitHub Enterprise Server见测试用例 index.test.ts。协议必须是 HTTPS回环地址localhost/127.x除外否则报GITHUB_ACTIONS_SERVER_PROTOCOL错误见 index.ts。读取失败不阻断某个仓库的 refs 读取失败例如私有仓库无权限时pnpm 会跳过该 action 并发出globalWarn警告错误信息经过redactAndSanitize脱敏不会影响其他 action 的检查index.ts。并发控制对仓库的远程读取使用pLimit(8)限制并发index.ts避免一次性发起大量git ls-remote。去重与排序结果按 action 名称去重并排序输出dedupeOutdatedindex.ts。与docker://引用的区别uses: docker://alpine:3.20这类 Docker 镜像引用不属于 GitHub Actions 依赖不会被检查parseActionReference中显式排除index.ts。只扫描 jobs / steps 的uses字段工作流文件中只有jobs.job.uses、jobs.job.steps[].uses以及runs.steps[].uses会被视为依赖对应 index.ts 与 Rust 的 workflow.rs 中的路由发现逻辑。小结pnpm outdated/pnpm update对 GitHub self-repository 语法uses: $/.github/actions/setup的支持补齐了本地复合 action 与可复用工作流引用方式在依赖检查上的最后一块拼图无论开发者使用./还是$/pnpm 都能以相同路径解析并递归穿透本地 action 发现其中的第三方依赖配合固定 commit SHA 版本注释的更新策略让 CI 工作流的依赖管理达到与 npm 依赖同等的可观测、可审计水平。相关实现可在 pnpm11/deps/github-actions 与 pnpm/crates/github-actions 中进一步查看测试用例见 index.test.ts。赞分享包管理器开发工具CLI【免费下载链接】pnpmFast, disk space efficient package manager项目地址https://gitcode.com/gh_mirrors/pn/pnpm点击查看免费下载相关推荐AWS CLI 实战使用 update-repository-description 修改 CodeCommit 仓库描述AWS CLI 实战使用 update repository description 修改 CodeCommit 仓库描述 aws codecommit up开发工具云原生运维Terraform Guides 项目教程Terraform Guides 项目教程 1. 项目的目录结构及介绍 Terraform Guides 项目的目录结构如下 . ├── cloud mana包管理器开发工具CLIpnpm 的依赖图拓扑排序引擎深入解析 pnpm/deps.graph-sequencer 的实现与实战pnpm 的依赖图拓扑排序引擎深入解析 pnpm/deps.graph sequencer 的实现与实战 pnpm/deps.graph sequence包管理器开发工具CLI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
pnpm outdated / update 支持 GitHub Self-Repository 引用（`uses: $/`）的实现与实战
包管理器开发工具CLI【免费下载链接】pnpmFast, disk space efficient package manager项目地址https://gitcode.com/gh_mirrors/pn/pnpm点击查看免费下载导读本指南围绕 pnpm 在pnpm outdated与pnpm update中新增的 GitHub Actions 依赖识别能力展开当工作流使用 GitHub 官方 self-repository 语法uses: $/.github/actions/setup引用同仓库内的本地复合 actioncomposite action或可复用工作流时pnpm 会像对待./引用一样递归解析并检查其中锁定的第三方 action 版本。读完本文你将理解$/与./两种本地引用语法的区别、pnpm 的 opt-in 启用机制--include-github-actions与update.githubActions、底层源码实现原理以及可复现的测试验证方式。背景pnpm 如何把 GitHub Actions 当作依赖来管理pnpm 的outdated/update命令不仅能管理 npm 包还能扫描项目.github/workflows目录下的工作流文件把其中uses:字段引用的第三方 action 视为依赖并检查是否有新版本。这一能力封装在 pnpm11/deps/github-actionsTypeScript 实现以及 Rust 版本的 github-actions crate 中。需要注意GitHub Actions 依赖检查是默认关闭的。原因是读取这些依赖需要对每个被引用的仓库执行git ls-remote参见 github_actions.rs 中的注释与opted_in逻辑成本较高因此必须显式开启命令行参数pnpm outdated --include-github-actions或pnpm update --include-github-actions配置文件在.npmrc/pnpm-workspace.yaml中设置update.githubActionstrue# 检查 GitHub Actions 依赖是否过期 pnpm outdated --include-github-actions # 直接更新 GitHub Actions 依赖默认更新到 caret 兼容的最新版 pnpm update --include-github-actions对应的 opt-in 判定逻辑在源码中实现为// pnpm11/deps/github-actions/src/index.ts export function shouldCheckGitHubActions (opts: GitHubActionsOptInOptions): boolean { return opts.includeGithubActions true || opts.updateConfig?.githubActions true }核心新能力识别uses: $/self-repository 本地引用GitHub 的$/语法是什么在 GitHub Actions 中引用当前仓库内部的复合 action 或可复用工作流有两种写法语法含义示例./仓库相对路径旧写法uses: ./.github/actions/setup$/self-repository 语法仓库根锚定uses: $/.github/actions/setup$/是 GitHub 官方提供的仓库自引用语法显式表示从当前仓库根目录解析语义上等价于./但更清晰地表达引用本仓库内的资源这一意图。pnpm 的新改动正是让pnpm outdated和pnpm update在扫描工作流时把$/与./同等对待——两者都会被当作本地引用去解析并继续递归扫描其引用的第三方 action。源码实现一处解析两种前缀在 TypeScript 实现中本地引用的识别集中在parseLocalReference与resolveLocalReference两个函数index.ts/** * Returns the repository-relative path of a uses: value that points into the * same repository, either the workspace-relative ./ form or GitHubs * self-repository $/ form. Returns null for every other value, such as an * owner/reporef or docker:// reference, which is left to * parseActionReference. */ function parseLocalReference (value: string): string | null { return value.startsWith(./) || value.startsWith($/) ? value.slice(2) : null }关键点在于./和$/去掉前缀后剩下的都是仓库根目录下的相对路径例如.github/actions/setup因此解析逻辑可以完全共用。resolveLocalReference随后完成路径解析与安全校验若引用指向.yml/.yaml文件直接使用该文件否则按action.yml/action.yaml的顺序在目标目录下查找对解析结果执行fs.realpath并用isSubdir校验其必须位于项目根目录之内防止路径逃逸对应错误GITHUB_ACTIONS_WORKFLOW_OUTSIDE_ROOT参考 workflow.rs 中 Rust 实现的同等校验。Rust 实现采用完全一致的策略workflow.rsif let Some(local) value .strip_prefix(./) .or_else(|| value.strip_prefix($/)) { if let Some(candidate) resolve_local_reference(root, canonical_root, local).await? { scan.local_references.push(candidate); } continue; }递归跟随本地 action 内部的第三方依赖也能被发现识别出本地引用后pnpm 并不会停在本地 action 这一层而是将其action.yml/action.yaml或可复用工作流文件加入扫描队列继续解析。例如下面这个典型的 monorepo 场景# .github/workflows/ci.yml name: CI on: [push] jobs: test: runs-on: ubuntu-latest steps: - uses: $/.github/actions/setup # 本仓库内的复合 action - uses: actions/checkoutv4.1.0 # 第三方 action会被检查版本# .github/actions/setup/action.yml name: setup runs: using: composite steps: - uses: actions/setup-nodev4.2.0 # 藏在本地 action 里的第三方依赖此时pnpm outdated --include-github-actions会穿透$/.github/actions/setup发现其中的actions/setup-nodev4.2.0并检查其是否有更新版本——这正是 test/index.test.ts 中 follows self-repository references to local composite actions 测试所验证的行为test(follows self-repository references to local composite actions, async () { const dir await fixture({ .github/workflows/ci.yml: jobs: test: steps: - uses: $/.github/actions/setup , .github/actions/setup/action.yml: runs: using: composite steps: - uses: actions/checkoutv4.1.0 , }) // findOutdatedGitHubActions 能返回 actions/checkout 的过期信息 })Rust 侧同样有对应测试tests.rs其中直接构造了uses: $/.github/actions/setup的用例。版本比较策略如何判定过期$/支持只是入口识别的一部分识别出 action 之后pnpm 会对其引用的仓库执行版本发现与语义化比较读取仓库引用对每个 action 仓库执行git ls-remote通过getRepoRefs解析refs/tags/vX.Y.Z形式的标签index.ts确定当前版本findCurrentVersion支持v1.2.3、v1、40 位 commit SHA配合行内注释# v1.2.3等多种引用形式index.ts计算 wanted / latest若当前版本是预发布版则在全部版本中选否则在稳定版本中用^当前版本的 caret 规则选出wanted兼容更新并取最新版作为latest更新写入updateGitHubActions默认更新到wantedcaret 兼容传入latest: true才允许不兼容的大版本更新。写入时总是固定到精确 commit SHA并把对应语义化版本号写入行内注释- uses: actions/checkout9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0如果工作流文件在解析过程中被外部修改源文件片段与记录的原始值不匹配pnpm 会抛出GITHUB_ACTIONS_WORKFLOW_CHANGED错误并提示重试避免并发编辑造成损坏index.ts。实战操作示例下面以一个真实的 monorepo 为例演示完整的检查与更新流程。步骤 1启用检查并查看过期情况pnpm outdated --include-github-actions输出类似字段含义见 index.ts 中的OutdatedGitHubAction接口┌─────────────────────────────────────────┬────────────┬────────┬──────────┐ │ name │ current │ latest │ wanted │ ├─────────────────────────────────────────┼────────────┼────────┼──────────┤ │ actions/checkout │ 4.1.0 │ 5.0.0 │ 4.2.0 │ │ owner/tool (via ./.github/actions/setup)│ 2.0.0 │ 2.1.0 │ 2.1.0 │ └─────────────────────────────────────────┴────────────┴────────┴──────────┘其中wanted是 caret 兼容的最新版latest是最新发布版。若只想看兼容更新可设置compatible: true。步骤 2执行更新# 默认更新到 caret 兼容版本推荐避免破坏性变更 pnpm update --include-github-actions # 允许跨大版本更新 pnpm update --include-github-actions --latest更新会以精确 commit SHA 版本注释的形式直接改写.github/workflows/*.yml并自动跟随$//./引用的本地复合 action。步骤 3选择性更新按名称过滤与 npm 包一样可以用 selector 过滤要更新的 action例如pnpm update --include-github-actions actions/checkout内部通过isGitHubActionSelector区分 action selector 与 npm 包 selector含/且不以开头视为 action并用normalizeGitHubActionSelector去掉ref后缀做匹配index.ts。实现细节与注意事项服务器地址action 的 git 地址与 homepage 默认使用GITHUB_SERVER_URL环境变量未设置时回退到https://github.com支持 GitHub Enterprise Server见测试用例 index.test.ts。协议必须是 HTTPS回环地址localhost/127.x除外否则报GITHUB_ACTIONS_SERVER_PROTOCOL错误见 index.ts。读取失败不阻断某个仓库的 refs 读取失败例如私有仓库无权限时pnpm 会跳过该 action 并发出globalWarn警告错误信息经过redactAndSanitize脱敏不会影响其他 action 的检查index.ts。并发控制对仓库的远程读取使用pLimit(8)限制并发index.ts避免一次性发起大量git ls-remote。去重与排序结果按 action 名称去重并排序输出dedupeOutdatedindex.ts。与docker://引用的区别uses: docker://alpine:3.20这类 Docker 镜像引用不属于 GitHub Actions 依赖不会被检查parseActionReference中显式排除index.ts。只扫描 jobs / steps 的uses字段工作流文件中只有jobs.job.uses、jobs.job.steps[].uses以及runs.steps[].uses会被视为依赖对应 index.ts 与 Rust 的 workflow.rs 中的路由发现逻辑。小结pnpm outdated/pnpm update对 GitHub self-repository 语法uses: $/.github/actions/setup的支持补齐了本地复合 action 与可复用工作流引用方式在依赖检查上的最后一块拼图无论开发者使用./还是$/pnpm 都能以相同路径解析并递归穿透本地 action 发现其中的第三方依赖配合固定 commit SHA 版本注释的更新策略让 CI 工作流的依赖管理达到与 npm 依赖同等的可观测、可审计水平。相关实现可在 pnpm11/deps/github-actions 与 pnpm/crates/github-actions 中进一步查看测试用例见 index.test.ts。赞分享包管理器开发工具CLI【免费下载链接】pnpmFast, disk space efficient package manager项目地址https://gitcode.com/gh_mirrors/pn/pnpm点击查看免费下载相关推荐AWS CLI 实战使用 update-repository-description 修改 CodeCommit 仓库描述AWS CLI 实战使用 update repository description 修改 CodeCommit 仓库描述 aws codecommit up开发工具云原生运维Terraform Guides 项目教程Terraform Guides 项目教程 1. 项目的目录结构及介绍 Terraform Guides 项目的目录结构如下 . ├── cloud mana包管理器开发工具CLIpnpm 的依赖图拓扑排序引擎深入解析 pnpm/deps.graph-sequencer 的实现与实战pnpm 的依赖图拓扑排序引擎深入解析 pnpm/deps.graph sequencer 的实现与实战 pnpm/deps.graph sequence包管理器开发工具CLI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
