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

Make quality snapshot comments safe for fork PRs

Fechada
  • Algo errado?
#522 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
65/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Pouca atividade
Stack de tecnologia
github-actions
Domínio
ci-cd, security

Direção de pesquisa

Comece pelos workflows performance e coverage pull_request, especialmente pelas etapas in-progress e final marocchino/sticky-pull-request-comment. Use PR #521 e as execuções vinculadas de performance e coverage para reproduzir a falha do token do fork. Está concluído quando os jobs dos forks forem concluídos com acesso somente leitura enquanto os gates permanecerem fail-closed, os comentários no mesmo repositório continuarem funcionando e os relatórios permanecerem disponíveis nos resumos e artefatos.

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

Descrição

bug needs PR

Problem

Pull requests from forks receive a read-only GITHUB_TOKEN, even when a pull_request workflow declares pull-requests: write. The performance and coverage workflows currently invoke marocchino/sticky-pull-request-comment before running their substantive work.

PR #521 reproduced the failure across all performance and coverage jobs:

  • the workflow token had PullRequests: read and Secret source: None;
  • the initial sticky-comment step failed with Resource not accessible by integration;
  • normal benchmark/coverage steps were then skipped because the preceding step failed;
  • always() upload/comparison steps ran without metrics.json or lcov.info, producing cascading snapshot failures; and
  • the final sticky-comment step failed with the same permission error.

The regular build, test, lint, and environment jobs passed, confirming that this was a fork-permission failure rather than a problem with the action pins in PR #521.

Security constraint

Fork workflows must remain untrusted and read-only:

  • do not grant fork pull requests write access or repository secrets;
  • do not use pull_request_target to execute or otherwise consume untrusted pull-request code; and
  • do not weaken the fail-closed behavior of the actual performance and coverage gates.

Tasks

  • Detect fork pull requests before invoking PR-comment-writing actions.
  • Skip both in-progress and final sticky-comment steps when the token cannot write, while allowing the benchmark/coverage work and snapshot comparisons to continue.
  • Ensure comment publishing itself is non-gating: a comment API failure must not suppress or replace the underlying quality-gate result.
  • Preserve sticky performance and coverage comments for same-repository pull requests.
  • Keep reports available to fork contributors through job summaries and uploaded artifacts.
  • Audit other pull_request workflows for write operations with the same fork-token assumption.

Acceptance criteria

  • A fork PR runs the complete performance and coverage jobs using only a read-only token.
  • Fork runs do not attempt to create or update PR comments and do not report Resource not accessible by integration.
  • Performance or coverage regressions still fail their jobs for both fork and same-repository PRs.
  • Missing or malformed benchmark/coverage output still fails closed.
  • Same-repository PRs continue receiving sticky snapshot comments.
  • Fork reports remain inspectable in the GitHub step summary and artifacts.
  • The solution does not use pull_request_target, expose secrets, or grant write permissions to untrusted fork code.

Reproduction

Linguagem predominante
Rust
Estrelas
207
Forks
45
Merge médio
1d 4h
PRs com merge (30d)
18

Preparar o ambiente

Abrir no Codespaces

Inicia o contêiner de desenvolvimento do projeto no navegador, com a sua própria conta do GitHub.

  • Sem Dockerfile nem arquivo Docker Compose
  • Sem modelo de pull request
  • Sem guia de contribuição

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 microsoft/python-environment-tools

Todas as issues de microsoft/python-environment-tools

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.