Skip to content
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

BUG: Patch Maintainers Annotations #4048

Closed
10 of 12 tasks
gabibguti opened this issue Apr 22, 2024 · 3 comments
Closed
10 of 12 tasks

BUG: Patch Maintainers Annotations #4048

gabibguti opened this issue Apr 22, 2024 · 3 comments
Assignees
Labels
kind/bug Something isn't working
Milestone

Comments

@gabibguti
Copy link
Contributor

gabibguti commented Apr 22, 2024

Describe the bug
Some things still need to be addressed in Maintainers Annotation feature (regarding PR #3905):

@gabibguti gabibguti added the kind/bug Something isn't working label Apr 22, 2024
@gabibguti
Copy link
Contributor Author

Related to: #1907

@raghavkaul
Copy link
Contributor

raghavkaul commented Jun 6, 2024

Do we need to pass in checks here? Also this doesn't work if you only run a subset of checks but there's an annotation for a check which isn't being run.

We should not pass checks []string here, but there's an import cycle b/w checks and config which means we can't use checks.GetAll in this file to validate the YAML against available checks in Scorecard. Looking into this.

Define if one invalid check or reason during the config parsing should invalidate the whole config, or if it should be logged and skipped.

I think this should be all-or-nothing: maintainers should validate the annotation file by running scorecard on their repo locally before committing it. Closing.

When might a valid annotation file become invalid over time?

  • valid reason is removed
  • check is removed

Neither of these cases is typical.

@spencerschrock
Copy link
Contributor

  • Define if in the case a check is annotated it should not be removed from SARIF result runs. Or, if is working as expected and we should not populate runs if there are no relevant results for that check

Based on this comment, I think the runs field should continue to be populated:

scorecard/pkg/sarif.go

Lines 644 to 649 in 9cd1fb8

// We need to create a run entry even if the check is disabled or the policy is satisfied.
// The reason is the following: if a check has findings and is later fixed by a user,
// the absence of run for the check will indicate that the check was *not* run,
// so GitHub would keep the findings in the dashboard. We don't want that.
category, err := computeCategory(sarifCheckName, doc.GetSupportedRepoTypes())
if err != nil {

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Something isn't working
Projects
Status: Done
Development

No branches or pull requests

3 participants