-
Notifications
You must be signed in to change notification settings - Fork 510
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
✨ enforce check scores are between the min and max #3769
Conversation
if the score is invalid, the Error field is set and the score is replaced with an inconclusive result score. Signed-off-by: Spencer Schrock <[email protected]>
Callers who want the score should use the CreateInconclusiveResult function. The goal is partly to enforce a consistent coding style, and partly to limit proportions which score to -1 accidentally. Signed-off-by: Spencer Schrock <[email protected]>
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #3769 +/- ##
==========================================
- Coverage 75.49% 70.64% -4.86%
==========================================
Files 230 230
Lines 15624 15621 -3
==========================================
- Hits 11795 11035 -760
- Misses 3103 3911 +808
+ Partials 726 675 -51 |
/scdiff generate |
/scdiff generate Dependency-Update-Tool,Packaging,Branch-Protection,Code-Review,Vulnerabilities,CII-Best-Practices,Fuzzing,Pinned-Dependencies,Binary-Artifacts,Token-Permissions,Dangerous-Workflow,License,Maintained,Signed-Releases,Contributors,SAST,Security-Policy,CI-Tests I'll need to debug the scdiff workflow later to see why the "no checks specified" invocation didn't work. |
What kind of change does this PR introduce?
feature / bug fix combined?
What is the current behavior?
there was no logic on what the scores could be
What is the new behavior (if this is a feature change)?**
if the score is invalid, the Error field is set and the score is replaced with an inconclusive result score.
Which issue(s) this PR fixes
Related to #3766
Special notes for your reviewer
I have this split into two commits, because I'm not certain about forcing callers who want
InconclusiveResultScore
to useCreateInconclusiveResult
, but I think it's the right decision. The goal is partly to enforce a consistent coding style, and partly to limit proportions which score to -1 accidentally.Does this PR introduce a user-facing change?
For user-facing changes, please add a concise, human-readable release note to
the
release-note
(In particular, describe what changes users might need to make in their
application as a result of this pull request.)