Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

feat(ci): validate workflow actions against repository policy

Ouverte
#3,624 2 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
45/100
Type d'issue
Fonctionnalité
Clarté
Clairement spécifiée
Activité
Active
Stack technique
github-actions, rust
Domaine
ci-cd, devtools

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

github_actions topic:testing

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.

Langage dominant
Rust
Étoiles
8.7k
Forks
1.3k
Merge moyen
2 j 6 h
PR mergées (30 j)
297

Guide de contribution

Ouvrir le guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de NVIDIA/OpenShell

Toutes les issues de NVIDIA/OpenShell

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.