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
From #2308 (review), we notice that there are more webhooks coming in from GitHub than we thought, and we need to do a better job of filtering these. For example, when we merge a PR from dependabot, there are two push actions happening: one to master and another to the branch in question.
We don't currently do any filtering on branch or tag name. However, the following information is available to us:
ref: The git ref resource. Could be a branch name (e.g., refs/heads/master) or a tag (v1.0.2)
ref_type: The type of Git ref object created in the repository. Can be either branch or tag.
master_branch: The name of the repository's default branch (usually main or in our case currently, master).
From #2308 (review), we notice that there are more webhooks coming in from GitHub than we thought, and we need to do a better job of filtering these. For example, when we merge a PR from dependabot, there are two
push
actions happening: one tomaster
and another to the branch in question.We don't currently do any filtering on branch or tag name. However, the following information is available to us:
ref
: The git ref resource. Could be a branch name (e.g.,refs/heads/master
) or a tag (v1.0.2
)ref_type
: The type of Git ref object created in the repository. Can be eitherbranch
ortag
.master_branch
: The name of the repository's default branch (usuallymain
or in our case currently,master
).So I guess pseudo logic would be:
Probably the place to do this is
requestFilter()
heretelescope/tools/autodeployment/server.js
Line 116 in 29951b7
The text was updated successfully, but these errors were encountered: