You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When building the status_string with something like "Failed: xyz's pull_request #X from Y to Z", the description sometimes includes pull requests from external repositories (forks) that reference a particular commit. This is very surprising and makes the notification look like it's coming from someone else's fork.
Here's an example:
This was actually not a pull request at all, but a scheduled workflow. The latest commit included with the workflow run also appears in the pull requests of two separate forks that are using a pull request bot to synchronize commits with their fork, so GitHub includes them in the pull_requests field of the API. This also happens with pushes directly to a branch.
`<${workflow_run.repository.html_url}/pull/${pull_request.number}|#${pull_request.number}> from \`${pull_request.head.ref}\` to \`${pull_request.base.ref}\``
)
.join(', ')
These lines could filter by the owner/repo of the current workflow run to ensure this PR data is for the current repo, not a fork. In our case, this should filter out all PRs attached to this workflow, and fall back to the description of the workflow run, not a PR.
The text was updated successfully, but these errors were encountered:
Current behavior:
When building the
status_string
with something like "Failed: xyz'spull_request
#X fromY
toZ
", the description sometimes includes pull requests from external repositories (forks) that reference a particular commit. This is very surprising and makes the notification look like it's coming from someone else's fork.Here's an example:
This was actually not a pull request at all, but a scheduled workflow. The latest commit included with the workflow run also appears in the pull requests of two separate forks that are using a pull request bot to synchronize commits with their fork, so GitHub includes them in the
pull_requests
field of the API. This also happens with pushes directly to a branch.Suggested fix:
slack-workflow-status/src/main.ts
Lines 164 to 169 in de07ba9
These lines could filter by the owner/repo of the current workflow run to ensure this PR data is for the current repo, not a fork. In our case, this should filter out all PRs attached to this workflow, and fall back to the description of the workflow run, not a PR.
The text was updated successfully, but these errors were encountered: