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
Is your feature request related to a problem? Please describe.
I'd like the dependency review action to have an option to create a commit status check to indicate the success or failure of the dependency review independently from the status of the workflow itself.
This would allow the dependency review action to work similarly to CodeQL - the success of the action itself would be (optionally) independent from the "dependency failures", allowing developers to enforce that dependency review is "run" but still have granular control over whether or not the dependency check "report" itself is enforced. This would be a more involved PR, so I'd like to do it after the 'quick fix' to comment-summary-in-pr: on-failure.
Describe the solution you'd like
Add an optional input parameter for dependency-review-action to enable the creation of a commit status check:
If no dependency issues are found or warn-only: true is set, the commit state will be set to success.
If dependency issues are found and warn-only: false (or the default) is set, the commit state will be set to 'failure'.
The target_url of the commit status will point at the workflow run containing the action. This allows users to easily navigate to a full dependency report.
Commit status checks should be used instead of check runs because check runs only offer support for GitHub Applications. Creating a check run from a workflow action can result in the check run being randomly attached to a different workflow since all workflows get grouped together into the same check suite.
Describe alternatives you've considered
Leaving the required workflow in Evaluate mode and setting warn-only: false. This would make it impossible to enforce a requirement to address vulnerable dependencies without also enforcing the workflow running. At an enterprise-level it would be a negative user experience if pull requests were blocked due to a workflow failure (edge case).
Set warn-only: true on shared required workflow. Setting this value wouldn't allow repository administrators to opt-in to enforcing that dependency review problems be addressed in pull requests
Additional context
This issue was created to separate out discussion from #817 (comment)
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
I'd like the dependency review action to have an option to create a commit status check to indicate the success or failure of the dependency review independently from the status of the workflow itself.
This would allow the dependency review action to work similarly to CodeQL - the success of the action itself would be (optionally) independent from the "dependency failures", allowing developers to enforce that dependency review is "run" but still have granular control over whether or not the dependency check "report" itself is enforced. This would be a more involved PR, so I'd like to do it after the 'quick fix' to comment-summary-in-pr: on-failure.
Describe the solution you'd like
Add an optional input parameter for
dependency-review-action
to enable the creation of a commit status check:warn-only: true
is set, the commit state will be set tosuccess
.warn-only: false
(or the default) is set, the commit state will be set to 'failure'.target_url
of the commit status will point at the workflow run containing the action. This allows users to easily navigate to a full dependency report.Describe alternatives you've considered
Evaluate
mode and settingwarn-only: false
. This would make it impossible to enforce a requirement to address vulnerable dependencies without also enforcing the workflow running. At an enterprise-level it would be a negative user experience if pull requests were blocked due to a workflow failure (edge case).warn-only: true
on shared required workflow. Setting this value wouldn't allow repository administrators to opt-in to enforcing that dependency review problems be addressed in pull requestsAdditional context
This issue was created to separate out discussion from #817 (comment)
The text was updated successfully, but these errors were encountered: