Feedback: moving from SHA pins to a lockfile lets Dependabot propose unmerged branches

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

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

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

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
39/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
github-actions, go
領域
cli, security

調査の方向性

Start by reading the ref resolution and narrowing behavior in the CLI, especially the path that rewrites SHA pins to tags, and inspect related discussion in #130. The report gives reproducible cases and asks whether to warn or flag version-like branches, but leaves the intended behavior open; clarify the desired outcome before implementation. Done should include a decided behavior and coverage for the reported SHA, tag, and branch cases.

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

説明

We tested how Dependabot handles an unmerged branch named like a version. Some of this may belong in dependabot-core, but the outcome changes when a repo moves to a lockfile, and Dependabot regenerates actions.lock through this CLI. Are you aware of it, and should something change?

What we saw

An action repo has a release tag v0.1.0 and an unmerged v1 branch, with no v1 tag. Dependabot's result depends on how the consumer pins the action:

Consumer pin Dependabot
@f95b8e2... # v0.1.0 (SHA on a tagged commit) No PR
@v0.1.0 PR to @v1
@v0.1.0 with actions.lock PR to @v1, lockfile included

Before lockfiles we pinned by SHA. Running gh actions-lock on our SHA consumer rewrote the uses: line and dropped the version comment:

-      - uses: getplumber-examples/print-version-demo@f95b8e245021b29ca2ed35c1f14589a12142b068 # v0.1.0
+      - uses: getplumber-examples/[email protected]

--no-narrow keeps the SHA, as mentioned in #130, but a default run doesn't. So a repo that adopts the lockfile with a default run goes from the first row of the table to the third, and starts getting a proposal it didn't get before. We ran one test of each pin, only with a SHA on a tagged commit, and we didn't run Dependabot on a --no-narrow lockfile.

The Dependabot PR changes the lockfile like this:

-    'getplumber-examples/[email protected]':
-        ref: 'v0.1.0'
-        commit: 'sha1-f95b8e245021b29ca2ed35c1f14589a12142b068'
+    'getplumber-examples/print-version-demo@v1':
+        ref: 'v1'
+        commit: 'sha1-62fd2ca978b7b2e6e61a02583cd70605527f50f0'

gh actions-lock --verify passes on the PR branch, and the PR's run executes the unmerged code. ref: 'v1' looks the same as a major version tag, so a reviewer can't tell from the diff that a branch replaced the release. Branch refs are fine when someone picks them on purpose, like @main. Here the branch only got picked because its name looks like a version.

The lockfile still helped: when v1 moved, the re-run kept the locked commit, while a consumer without a lockfile ran the new code. When v1 was deleted, the runner refused the pin and --verify failed with Ref no longer exists.

We used gh-actions-lock v0.4.0 for the local runs. No Require lockfile policy was set, and --verify ran locally, not in CI.

Questions
  1. Is this known, and is it expected?
  2. Should gh actions-lock warn when it rewrites a SHA pin to a tag, since Dependabot's updates change with it?
  3. Would a finding make sense when a version-like ref resolves to a branch? The CLI already tells tags and branches apart when it resolves a ref.
  4. Or is this only for Dependabot's version selection? If so, I'll open an issue on dependabot-core.
主要言語
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 を短くまとめたダイジェスト。