Skip to content

chore(deps): bump the production-dependencies group across 1 directory with 6 updates #630

chore(deps): bump the production-dependencies group across 1 directory with 6 updates

chore(deps): bump the production-dependencies group across 1 directory with 6 updates #630

name: Contract Guard
on:
pull_request:
branches: [develop]
types: [opened, edited, synchronize, reopened, ready_for_review]
permissions:
contents: read
concurrency:
group: contract-guard-${{ github.event.pull_request.number || github.ref }}
cancel-in-progress: ${{ github.event_name == 'pull_request' }}
jobs:
gitnexus-contract:
name: Contract Guard / gitnexus-contract
# 这道门禁要求两样 dependabot 结构上给不出的东西:改动 critical 文件时必须
# 同 PR 带一个 scripts/tests/ 契约测试(见 contract-rules.mjs 的 repo-harness
# 规则),以及 PR 正文里的结构化 GitNexus impact summary。dependabot 的 PR
# 正文是它自己生成的 release notes,也不会顺手改测试,因此任何碰
# .github/workflows/ 的版本升级都必然红——一个永远红的 check 会训练维护者
# 忽略 check,而不是提高安全性。dependabot 升级的把关交给 CODEOWNERS 的
# 人工审阅 + CI 这道必需门禁。repo-guard.yml 出于同样的理由跳过 dependabot。
#
# 判定用 PR 作者,而不是 repo-guard.yml 那样的
# `github.actor != 'dependabot[bot]'`:维护者一旦对 dependabot 分支执行
# update-branch 或补一次推送,actor 就变成维护者本人,用 actor 判定会让这道
# 必然失败的门禁重新出现。作者字段不随推送者变化。
#
# 代价是这条豁免比「dependabot 的自动升级」更宽:维护者推到 dependabot/*
# 分支上的任何提交同样不过门禁,应按「门禁没跑过」来审。见
# docs/knowledge-contract.md 的 CI Contract 一节。
if: github.event.pull_request.user.login != 'dependabot[bot]'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@d23441a48e516b6c34aea4fa41551a30e30af803 # v6.1.0
with:
fetch-depth: 0
- uses: pnpm/action-setup@0ebf47130e4866e96fce0953f49152a61190b271 # v6.0.9
- uses: actions/setup-node@249970729cb0ef3589644e2896645e5dc5ba9c38 # v6.5.0
with:
node-version: 22
cache: pnpm
- run: pnpm install --frozen-lockfile
- run: pnpm contract:gitnexus
env:
GITNEXUS_IMPACT_SUMMARY: ${{ github.event.pull_request.body }}