Make quality snapshot comments safe for fork PRs

オープン
#522 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
65/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
静か
技術スタック
github-actions
領域
ci-cd, security

調査の方向性

performance と coverage の pull_request ワークフローから始め、特にそれらの in-progress および final の marocchino/sticky-pull-request-comment ステップを確認します。PR #521 とリンクされた performance および coverage の実行を使用して、fork のトークン失敗を再現します。Fork のジョブが読み取り専用アクセスで完了し、同時にゲートが fail-closed のままで、同一リポジトリのコメントが引き続き機能し、レポートがサマリーとアーティファクトで引き続き利用可能になれば完了です。

索引モデルが issue の本文から書いたものです。

説明

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

主要言語
Rust
スター
207
フォーク
45
PR マージ指標
30日以内にマージされた PR はありません

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

microsoft/python-environment-tools のほかの issue

microsoft/python-environment-tools の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。