The scorecard-action validates that the event is either pull_request or that GITHUB_REF matches the default branch, which prevents it from running in GitHub merge queues where the event is merge_group and the ref is refs/heads/gh-readonly-queue/....
|
if !o.isPullRequestEvent() && |
|
!o.isDefaultBranch() { |
|
fmt.Printf("%s not supported with %s event.\n", o.GithubRef, o.GithubEventName) |
|
fmt.Printf("::error ::Only the default branch %s is supported.\n", o.DefaultBranch) |
My use case is gating the merge queue on critical scorecard findings, ideally using the same action that publishes results on the default branch. The only workaround today is to install and run the scorecard CLI directly, since GITHUB_* environment variables are read-only in Actions and cannot be overridden.
A minimal fix would be to relax the branch/event validation when publish_results is false. I think other triggers like issue_comment for on-demand runs could also be relaxed in the same way.
The scorecard-action validates that the event is either
pull_requestor thatGITHUB_REFmatches the default branch, which prevents it from running in GitHub merge queues where the event ismerge_groupand the ref isrefs/heads/gh-readonly-queue/....scorecard-action/options/options.go
Lines 122 to 125 in 05bb7c6
My use case is gating the merge queue on critical scorecard findings, ideally using the same action that publishes results on the default branch. The only workaround today is to install and run the scorecard CLI directly, since
GITHUB_*environment variables are read-only in Actions and cannot be overridden.A minimal fix would be to relax the branch/event validation when
publish_resultsisfalse. I think other triggers likeissue_commentfor on-demand runs could also be relaxed in the same way.