Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

feat(ci): validate workflow actions against repository policy

Aberta
  • Algo errado?
#3,624 2 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

@purp já está trabalhando nisso.

Desde 23/9/2026.

  • #3634 de @purp — aberto

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
45/100
Tipo de issue
Funcionalidade
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
github-actions, rust
Domínio
ci-cd, devtools

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
Rust
Estrelas
15.4k
Forks
1.7k
Merge médio
2d 3h
PRs com merge (30d)
374

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de NVIDIA/OpenShell

Todas as issues de NVIDIA/OpenShell

Issues semelhantes

Mais issues de Rust

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.