Feature request: Inherited organization and enterprise Action locks
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 25/100
調査の方向性
リポジトリのファイル、テスト、エントリーポイントは指定されていません。まず、要求されている inherited-lock の動作と、gh-actions-lock が現在対象としている生成および検証の範囲を比較し、その後、どの部分に GitHub Actions のサービスまたはポリシーによるサポートが必要かを判断してください。実装範囲について合意するか、適切な tracker にリダイレクトできれば完了です。
索引モデルが issue の本文から書いたものです。
説明
Is inherited Action-lock configuration in scope for the Workflow Dependency Pinning technical preview?
It would be useful for organization and enterprise owners to provide centrally managed Action-lock entries and require selected repositories to use an effective lock, even when those repositories do not contain .github/workflows/actions.lock.
For each action reference, resolution could follow:
repository lock > organization lock > enterprise lock
This would let central owners roll out reviewed, known-good Action pins without a repository-by-repository migration. A repository could inherit the organization or enterprise resolution without a local lockfile. Repository administrators could add a local lock entry when they need a permitted repository-specific resolution, or when they introduce an action/ref that is not covered by the organization or enterprise lock.
An organization or enterprise policy/ruleset could require an effective lock for selected repositories. Once enabled, a dependency missing from all applicable lock scopes should fail rather than resolve a mutable tag or branch live.
A practical rollout could be:
audit → generate and review central-lock entries from existing workflow dependencies → enforce
The generated central entries should capture the verified resolution at generation time. After enforcement, newly introduced references would require an approved central entry or a permitted repository-level entry.
This appears to need GitHub Actions service/policy and runtime support in addition to gh-actions-lock. I’m filing it here because it is related to the technical preview, but please redirect me if there is a better tracker for the broader design.
- 主要言語
- Go
- スター
- 295
- フォーク
- 21
- 平均マージ
- 1日 3時間
- マージ済み PR（30日）
- 64
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
github/gh-actions-lock のほかの issue
-
難易度 3/5 1〜2日 初心者へのやさしさ 58/100
github/gh-actions-lock#267 ·
メンテナーはふだん 1 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 30/100
github/gh-actions-lock#266 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 30/100
github/gh-actions-lock#264 · コメント 2 件 · リアクション 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 3/5 半日 初心者へのやさしさ 42/100
github/gh-actions-lock#262 ·
メンテナーはふだん 1 日以内に返信
-
Dependabot drops an unchanged transitive dependency when bumping a composite action対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープン
難易度 4/5 3〜5日 初心者へのやさしさ 30/100
github/gh-actions-lock#257 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
github/gh-actions-lock の issue をすべて見る
似ている issue
-
needs-triage
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信
-
enhancement needs-triage
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
valkey-io/valkey-operator#610 ·
メンテナーはふだん 3 日以内に返信
-
難易度 1/5 1時間未満 初心者へのやさしさ 85/100
-
WriterSetTimes: the UTIME_NOW check fails when the kernel uses its coarse clock対応中かも @JakeChampion が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
JakeChampion/lang#14224 ·
メンテナーはふだん 1 日以内に返信
-
agent-butler-finding bug
難易度 1/5 1時間未満 初心者へのやさしさ 88/100
jordansmall/spindrift#6391 ·
メンテナーはふだん 1 日以内に返信