-
Notifications
You must be signed in to change notification settings - Fork 400
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add benchmark CI (not from fork) #2369
Conversation
|
🤖 Benchmark Comparison for
|
🤖 Benchmark Comparison for
|
Codecov ReportPatch and project coverage have no change.
❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more. Additional details and impacted files@@ Coverage Diff @@
## main #2369 +/- ##
=======================================
Coverage 63.21% 63.21%
=======================================
Files 135 135
Lines 7032 7032
Branches 1185 1185
=======================================
Hits 4445 4445
Misses 2587 2587 ☔ View full report in Codecov by Sentry. |
So, I already have this PR open here (#2368). But it would appear that PRs opened from forks are given a read-only
GITHUB_TOKEN
—which makes sense when you realize that if it didn't, anyone could simply open a PR and then have full read/write permissions over all pull requests. So, I'm opening this PR from a separate branch within this repo, to make sure I do in fact have the ability to create a comment on this PR from within my custom action.UPDATE: Yup, it was successfully able to add the comment here. (#2369 (comment)) I'll do some research and see if I can come up with any workarounds or alternatives. It sure would be nice if there was a special "add comments to Pull Requests" permission, as that doesn't seem like such a crazy thing to do.
UPDATE AGAIN: Aha, so it appears the
pull_request_target
event is the solution. docsUPDATE 3: Ha. Turns out that it's not a good idea to use
pull_request_target
when you do any sort of building: https://securitylab.github.com/research/github-actions-preventing-pwn-requests/. The true recommended workaround would be to use two different workflows: one for checking out the PR code, running the benchmarks, and uploading the result as an artifact, and a second for downloading that artifact and commenting on the PR. A simpler option would be to post a markdown job summary, which will work with the normalpull_request
trigger and will not require multiple workflows.UPDATE 4: A job summary would look like this:
Here's an example from the zio-http workflow for a PR from a fork (you don't need special permissions to add a job summary, thankfully).