Read
GitHub Actions 本身没有显式的连线语法,所谓“节点”是三个层级,连接方式各不相同:
同一个 job 里的 steps 天然串行(同一 runner、同一文件系统),连线靠顺序,传值靠三个内置文件:
$GITHUB_OUTPUT
${{ steps.<id>.outputs.x }}
$GITHUB_ENV
${{ env.X }}
$GITHUB_PATH
你仓库的 release-cli-archive.yml 就是这个模式:
- name: Configure pnpm store path id: pnpm-store # 给节点命名 run: echo "path=$store_path" >> "$GITHUB_OUTPUT" - uses: actions/cache/restore@v4 # 下游节点引用上游输出 with: path: ${{ steps.pnpm-store.outputs.path }}
PNPM_CONFIG_STORE_DIR 走 $GITHUB_ENV,则是对之后所有步骤生效的连线。
PNPM_CONFIG_STORE_DIR
needs
jobs: build: { ... } test: needs: build # 边:build 成功后才跑 test
规则要点:
if: always()
if: needs.build.result == 'success'
needs.<job>.outputs.<name>
(a)workflow_run——事件级、异步、弱连接。 这正是你的 release-docker-image.yml:
workflow_run
on: workflow_run: workflows: ['Release CLI archive (dsh)'] # 上游 workflow 的 name types: [completed]
on: push: tags: ['dsh-v*']
image
if
completed
if: ${{ github.event_name != 'workflow_run' || github.event.workflow_run.conclusion == 'success' }}
github.event.workflow_run.*
head_branch
head_repository.full_name
conclusion
gh release upload
dsh-v<version>.zip
docker build --build-arg DSH_VERSION=...
(b)workflow_call——可复用工作流、同步、强连接。 如果想让上游 uses: ./.github/workflows/x.yml 直接调用,就能传 inputs / secrets / outputs,是真正的“函数调用”式连线。你的两个文件没用这种,而是用了 workflow_run + release asset,因为发布产物本身需要作为 tag 的公开资产存在。
workflow_call
uses: ./.github/workflows/x.yml
inputs
secrets
outputs
concurrency
它不是连线,但决定同一 tag 上的节点是否互相打断:
concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: false
两个文件都设了 cancel-in-progress: false,含义是:同一 group 内新 run 排队而非取消旧 run,保证已开始的发布不被腰斩——这相当于给连线加了互斥锁。
cancel-in-progress: false
needs.<job>.outputs
concurrency.group
Github开源生信云平台 DEMO