Make quality snapshot comments safe for fork PRs
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 65/100
調査の方向性
performance と coverage の pull_request ワークフローから始め、特にそれらの in-progress および final の marocchino/sticky-pull-request-comment ステップを確認します。PR #521 とリンクされた performance および coverage の実行を使用して、fork のトークン失敗を再現します。Fork のジョブが読み取り専用アクセスで完了し、同時にゲートが fail-closed のままで、同一リポジトリのコメントが引き続き機能し、レポートがサマリーとアーティファクトで引き続き利用可能になれば完了です。
索引モデルが issue の本文から書いたものです。
説明
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: readandSecret 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 withoutmetrics.jsonorlcov.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_targetto 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_requestworkflows 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
- PR: #521
- Performance run: https://github.com/microsoft/python-environment-tools/actions/runs/31991321814
- Coverage run: https://github.com/microsoft/python-environment-tools/actions/runs/31991321855
- 主要言語
- Rust
- スター
- 207
- フォーク
- 45
- PR マージ指標
- 30日以内にマージされた PR はありません
コントリビューションガイド
このリポジトリのコントリビューションガイドは索引されていません
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
microsoft/python-environment-tools のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
-
microsoft/python-environment-tools#520 · コメント 2 件 · 担当者 1 名 ·
microsoft/python-environment-tools の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
Eynzof/Hermes-CN-Desktop#610 ·
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
gitbutlerapp/gitbutler#15998 · コメント 1 件 ·
-
bug triage:deciding
難易度 1/5 1時間未満 初心者へのやさしさ 88/100
open-telemetry/otel-arrow#4132 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100