Plain run drops a transitive `uses` edge when the transitive dependency is also used directly by the workflow (v0.4.1)

オープン
  • 何か問題がありますか？
#272 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
68/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
github-actions, go
領域
cli, devtools

調査の方向性

Start by tracing the plain-run lockfile generation path and how composite-action dependencies are merged when an action is also used directly; the payload does not name source files or tests. Reproduce with the supplied workflow scenario and compare the generated entry with --relock. Done when the composite action records both nested uses edges and --verify passes.

索引モデルが issue の本文から書いたものです。

説明

What happened

When a composite action is bumped and actions.lock is regenerated with a plain run (no --relock), the new entry for the composite action is missing one of its nested dependencies. That nested dependency is also used directly in the same workflow. Afterwards, gh actions-lock --verify fails:

✗ Lockfile doesn't match locked manifest dev-hato/actions-diff-pr-management@a3c6f1d6cb3f46d2f48ac3856ef603ef2e508061
  dev-hato/actions-update-dockle@b4b0d3fccf24fc77325c624f52a1a1bc9aa6d4b5 at locked commit b4b0d3fccf24 uses dev-hato/actions-diff-pr-management@a3c6f1d6cb3f46d2f48ac3856ef603ef2e508061, but its lockfile entry dev-hato/actions-update-dockle@b4b0d3fccf24fc77325c624f52a1a1bc9aa6d4b5 does not record it
  ! restore the edge from version control, or run `gh actions-lock --relock`
  ↳ .github/workflows/deploy-hato-bot.yml

This looks like #257, which was closed as fixed in v0.4.1. I can still reproduce this case on v0.4.1. The difference here is that the dropped dependency is also a direct dependency of the workflow. Because of that, its top-level dependencies entry stays, and only the uses edge under the composite action is lost.

Setup

dev-hato/actions-update-dockle is a composite action. At both the old and the new version, its action.yml uses:

  • actions/github-script@3a2844b7e9c422d3c10d287c895573f7108da1b3
  • dev-hato/actions-diff-pr-management@a3c6f1d6cb3f46d2f48ac3856ef603ef2e508061

.github/workflows/deploy-hato-bot.yml uses dev-hato/actions-update-dockle and also uses dev-hato/actions-diff-pr-management@a3c6f1d… directly.

Steps to reproduce
git clone https://github.com/dev-hato/hato-bot && cd hato-bot
git checkout c7022af77510eec4f8c14ea8b120293af11c7760
gh extension install github/gh-actions-lock --pin v0.4.1 --force

# bump the composite action (v0.0.149 -> v0.0.151)
perl -pi -e 's|dev-hato/actions-update-dockle\@[0-9a-f]+ # v[0-9.]+|dev-hato/actions-update-dockle\@b4b0d3fccf24fc77325c624f52a1a1bc9aa6d4b5 # v0.0.151|' \
  .github/workflows/deploy-hato-bot.yml

# same invocation Renovate uses
gh actions-lock --no-interactive --no-onboard --no-narrow --ignore-local-actions

gh actions-lock --verify --no-narrow   # fails

The resulting diff of actions.lock:

-    'dev-hato/actions-update-dockle@5538777ee98aa1b8016df625c17c6cbe25531f39':
-        ref: 'v0.0.149'
-        commit: 'sha1-5538777ee98aa1b8016df625c17c6cbe25531f39'
+    'dev-hato/actions-update-dockle@b4b0d3fccf24fc77325c624f52a1a1bc9aa6d4b5':
+        ref: 'v0.0.151'
+        commit: 'sha1-b4b0d3fccf24fc77325c624f52a1a1bc9aa6d4b5'
         owner_id: 68012105
         repo_id: 517688930
         uses:
             - 'actions/github-script@3a2844b7e9c422d3c10d287c895573f7108da1b3'
-            - 'dev-hato/actions-diff-pr-management@a3c6f1d6cb3f46d2f48ac3856ef603ef2e508061'

The plan output lists only one transitive dependency for the bumped action:

Pinned 1 action (+ 1 transitive) across 1 workflow
  dev-hato/actions-update-dockle@b4b0d3f
    └─ .github/workflows/deploy-hato-bot.yml
Transitive dependencies (from composite actions):
  actions/github-script@3a2844b via dev-hato/actions-update-dockle@b4b0d3fccf24fc77325c624f52a1a1bc9aa6d4b5
Expected behavior

The new entry for dev-hato/actions-update-dockle@b4b0d3f… should record both nested dependencies, including dev-hato/actions-diff-pr-management@a3c6f1d…, even though that action is already locked as a direct dependency of the workflow. --verify should then pass.

Current workaround
gh actions-lock --relock

This restores the missing edge, and --verify passes. But Renovate and Dependabot run plain mode, so every update PR for this action needs a manual relock.

Versions
  • gh-actions-lock v0.4.1 (local, CI verify, and Renovate)
  • Renovate 44.220.0

Related: #257

主要言語
Go
スター
295
フォーク
21
平均マージ
1日 3時間
マージ済み PR（30日）
64

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

github/gh-actions-lock のほかの issue

github/gh-actions-lock の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。