-
Notifications
You must be signed in to change notification settings - Fork 146
fix: add summary comment on failure when warn-only: true #827
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
elireisman
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank for you contributing this change! Also really appreciate the manual testing, this functionality is obtuse to unit test at the moment. That too is being tracked, appreciate you working around it for now 🙇
I'd be partial to sticking with the bool flag for fails until we have time for a larger refactor, but no need to deal with that now since we're not relying on the returned count itself yet anywhere public facing 👍
Before landing this change, you'll need to update the PR (NPM dist packaging) but otherwise LGTM
|
I've temporarily converted this back to a draft PR - I've updated to code to switch to using a boolean instead of a failure count. Will mark ready for review once I've run through the manual tests. |
|
@elireisman I've updated the PR to use booleans instead of a numeric "issue count" variable. I also noticed that Should be ready for review again now! |
|
👋 thanks again @ebickle - our team FR will have a look ASAP so we can get this shipped, appreciate it! |
Ahmed3lmallah
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👋 @ebickle, thanks again for your contribution. This LGTM. I will merge the PR and make a new release shortly after.
Fixes #817
Summary
When the parameter
warn-onlyis set totrue, allow a pull request comment to be created whencomment-summary-in-pris set toon-failure.Testing
The action was tested with the following scenarios:
warn-only: true,comment-summary-in-pr: alwayswarn-only: true,comment-summary-in-pr: on-failurewarn-only: true,comment-summary-in-pr: neverwarn-only: true,comment-summary-in-pr: alwayswarn-only: true,comment-summary-in-pr: on-failurewarn-only: true,comment-summary-in-pr: neverUnit tests have not been added since both
main.tsandcomment-pr.tscurrently lack unit test files. I looked at adding unit tests forcomment-pr.tsbut the static octokit constructor (new retryingOctokit) made this extremely difficult due tojest.mockhoisting. To make the file more testable,retryingOctokitshould be replaced with non-static logic, such as an update tooctokitClientinutils.tsthat would have an optional parameter to allow retries. This change would have been much larger and far beyond the scope of this pull request.Implementation decisions
config.comment_summary_in_pr === 'on-failure'test incomment-pr.tsto no longer rely on a non-zero exit code. To signal a failure, a new parameter was added to thecommentPrfunction.failureCount: numberwas used instead of a boolean to simplify the logic - it's much easier to incrementally do afailureCount +=than to try to do boolean logic on the same line as function calls. In addition,failureCountseemed more useful for future action logging.setFailedwithindeny.tswas moved out intoprintDeniedDependencies.failureCountvariable inmain.tscan be used for other future functionality, such as an implementation of Add option for commit status check #825