feat(ci): validate workflow actions against repository policy
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 45/100
Rechercherichtung
The issue is about adding a CI check to validate GitHub Actions workflow references against repository policy. Start by examining existing CI workflows in the repository, likely in a .github/workflows directory. Look for how workflow linting is currently implemented. The new check needs to fetch the effective repository policy, parse workflow files for uses: references, and compare them. The acceptance criteria detail what constitutes a valid reference. A good first step is to find the failing workflow from the investigation (run 35874219573) to understand the exact error and policy mismatch.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
User Story
As an OpenShell maintainer, I want pull-request CI to detect workflow action references that violate the repository GitHub Actions policy, so that release and maintenance workflows do not fail at startup after merge.
Problem Statement
Workflow linting currently checks syntax and security findings but does not validate external uses: references against the effective Actions permissions for the repository. A workflow can therefore pass pull-request checks and merge while referencing an action revision that GitHub rejects before any job starts.
Impact / Why This Matters
Maintainers discover these conflicts only when the affected workflow is triggered, which may happen during a release. The current workaround is to run the workflow after merge or manually compare every action SHA with a large policy allowlist. That is late, error-prone, and can block time-sensitive release work.
Proposed Design
When a pull request changes a GitHub Actions workflow or action definition, a required CI check should validate its external action and reusable-workflow references against the effective policy that GitHub will enforce for OpenShell. The check should report each rejected reference and enough policy context to choose an approved revision or request approval. Changes that do not affect workflow references should avoid unnecessary work.
Acceptance Criteria
- Pull requests that add or change external action or reusable-workflow references receive a policy compatibility check.
- The check evaluates the effective repository policy rather than relying on a separately maintained copy of the allowlist.
- A disallowed owner, repository, tag, or SHA fails before merge with an actionable annotation identifying the reference.
- Enterprise-owned, GitHub-owned, verified Marketplace, explicitly allowed, local, and reusable-workflow references are handled consistently with GitHub enforcement.
- Policy lookup or evaluation failures produce a clear diagnostic and cannot silently report success.
- Existing workflow syntax and security checks continue to run.
Alternatives Considered
Relying on manual review or post-merge workflow dispatch keeps the failure late and depends on maintainers noticing exact SHA-level allowlist mismatches. Maintaining a second allowlist in the repository risks drift from the GitHub policy and would not reliably predict enforcement.
Agent Investigation
Release Tag run 35874219573 failed with startup_failure before creating jobs because oras-project/setup-oras@38de303aac69abb66f3e6255b7198bff35f323e3 was not allowed. The effective repository policy allowed the same action only at 1d808f7d7f6995cc68b7bf507bfe5c5446e1dc9d.
- Vorherrschende Sprache
- Rust
- Sterne
- 8.7k
- Forks
- 1.3k
- Ø Merge
- 2 T. 6 Std.
- Gemergte PRs (30 T.)
- 297
Beitragsleitfaden
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus NVIDIA/OpenShell
-
area:docs
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 88/100
-
state:triage-needed
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
-
area:cli state:validated
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
-
state:triage-needed
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 90/100
-
area:build spike state:review-ready state:stale
Schwierigkeit 2/5 Ein halber Tag Anfängerfreundlichkeit 68/100
Alle Issues in NVIDIA/OpenShell
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
TheLarkInn/aipm#2413 ·
-
documentation
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 90/100
alexgorbatchev/simple-ptt#15 ·
-
tooling
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
-
todo:ticket
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
taikoxyz/taiko-mono#22168 · 1 Kommentar ·