Feature request: How should composite actions lock themselves?

オープン
#183 コメント 5 件 リアクション 0 件 担当者 0 名 GitHub で見る

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

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

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
活発
技術スタック
github-actions, go
領域
cli, security

調査の方向性

Start by reading the current lockfile format and its documented limitation for reusable workflows, then inspect how gh actions-lock reads and merges lockfiles. The issue raises alternatives for composite actions but does not settle the format or behavior; clarify the design before implementation. Done means composite action dependencies can be pinned consistently without weakening the integrity guarantees described here.

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

説明

area:composite-actions feature-request

This is somewhat related to https://github.com/github/gh-actions-lock/issues/139#issuecomment-6259216875 and has come up while I'm working on zizmor's support for lockfiles.

TL;DR: lockfiles are currently workflow-oriented, with reusable workflows as a documented limitation. But how should repos that contain composite actions pin their dependencies?

For example, in zizmor-action, we use the upload-serif action:

https://github.com/zizmorcore/zizmor-action/blob/fb1d87ba4b2f888025015a269a94ad7e991f6a7b/action.yml#L131

As is, lockfiles leave these kinds of composite actions with a bit of a gap:

  1. We can switch back to ref-pinning, and let downstream users lock as part of their resolution. However, this degrades the integrity/immutability property for users who haven't adopted lockfiles yet (or can't for whatever reason).
  2. We can keep hash-pinning our dependencies in the "old" way, but this is now out of sync with the idiom that's being established for locking workflows. In particular this means that tools like zizmor will need to have two pathways: a lockfile pathway for workflows, and a "you still have to do it the old way" for composite actions.

AFAICT this could be handled by allowing composite actions in the current lockfile format as well (keyed by repo-relative path?), and then having gh actions-lock honor the downstream lockfile when present/merge it into the upstream lockfile.

Alternatively it would be solved by the "intrinsic" idea in https://github.com/github/gh-actions-lock/issues/139#issuecomment-6259216875, since composite action definitions could grow similar dedicated syntax for pinning, etc.

主要言語
Go
スター
253
フォーク
15
平均マージ
19時間 30分
マージ済み PR(30日)
60

環境構築

はじめの一歩

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

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

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

似ている issue

Go の issue をもっと見る

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

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