Add preview links comment to PRs #1416
Conversation
reakaleek
force-pushed
the
feature/preview-comment
branch
from
6c1e4af to
b626770
Compare
reakaleek
changed the title
|
Label error. Requires exactly 1 of: automation, breaking, bug, changelog:skip, chore, ci, dependencies, documentation, enhancement, feature, fix, redesign. Found: DO NOT MERGE |
|
|
||
| if (links.length > 20) { | ||
| body.push(''); | ||
| body.push(`<sub>There are ${links.length - 20} more links...</sub>`); |
There was a problem hiding this comment.
do these additional links get exposed anywhere?
There was a problem hiding this comment.
Do you want them to be @shainaraskas ?
I guess we could hide the remainder in a <summary> in the comment?
There was a problem hiding this comment.
I think it would be nice to avoid having to track down a whole pile for very complex PRs - 20 is a little on the low side. a <summary> tag would be perfect.
wonder if there's a risk of this running away into the 1000s of links in case of some low-level find/replace or a bad/old branch, so we might still want to limit it to avoid perf issues (I'll let you decide whether this is necessary)
There was a problem hiding this comment.
My thinking was that more than 20 links are more overwhelming than helpful.
The majority of the current open PRs have one to five links. There are two outliers with 15+ links.
I'm happy to increase the number, but as you said, showing 1000s of links won't be useful.
Also, we need to consider the max pr comment character limit.
There was a problem hiding this comment.
I think there's a happy medium between 20 and 1000s 😉?
Could say
- if less than 10 just use standard comments as we have today
- if more than 10, whack em in a collapsible
- cap at something like 75-100 to handle edge cases without going crazy
| @@ -1,7 +1,7 @@ | |||
| name: preview-build | |||
|
|
|||
| on: | |||
| pull_request_target: | |||
| pull_request: | |||
There was a problem hiding this comment.
IIUC, this will not let you use write permissions scopes. Is that the expected behaviour?
There was a problem hiding this comment.
This is just the trigger of this worklfow in this repository.
I changed it to pull_request to be able to validate the changes on this PR.
But I also thought, I'll just keep it. As we seldom have fork contributions here.
the pull_request_target trigger is still valid in consumer repos.
Closes #1395
Changes
When the upload to s3 completes, comment on the PR with a list of changed files.
Related Issues
doc-preview-comment.ymlfunctionality to the doc build #1395 to be merged. (Adding thepull-requests: writepermission)