Skip to content

Conversation

@japroc
Copy link
Contributor

@japroc japroc commented Sep 4, 2025

Summary

  • add a sarif-issues CLI command that reads SARIF, correlates against existing GitHub issues, and manages issue lifecycle
  • enhance SARIF helpers (path resolution, code-flow formatting, correlation metadata) to support the new command
  • document the workflow, severity filters, dry-run output, and add supporting engineering notes

Documentation

Read sarif-issues reference doc for details: docs/reference/cmd-sarif-issues.md

@japroc japroc self-assigned this Sep 17, 2025
@japroc japroc added the enhancement New feature or request label Sep 17, 2025
@japroc japroc marked this pull request as ready for review October 12, 2025 14:34
…s to return closed issue count and handle logging improvements
…adata enrichment and required parameters validation
- Combined imports from both branches (sarifissues and upload)
- Integrated logger initialization from main branch
- Added all command initializations with proper logger parameters
- Fixed sarifissues.Init call to use correct signature (no logger parameter)
- Maintained all command registrations from both branches
…djust function signatures for improved logging
@japroc japroc requested a review from shikari-ac October 12, 2025 17:19
@japroc japroc changed the title issue vm draft New sarif-issues command to create , close github issue and manage the issues lifecycle Oct 12, 2025
@shikari-ac
Copy link
Contributor

shikari-ac commented Oct 13, 2025

General comment. There are several single-feature dependencies (see files in cmd/sarif-issues) that could be reused elsewhere. I’m working on generalizing them into reusable modules. The plan is to reuse the same logic for parsing SARIF and creating/closing findings to support inline PR comments.

Overall, the code looks good to me. We can refactor further as more requirements arrive. I’m already covering part of this in cmd/sarif-comments. In general, I recommend creating globally available dependencies to avoid tight coupling to any specific cmd/feature.


I do have a concern about streaming the list of open issues over RPC. I’m using the same approach for PR comments. Is there any throughput limit where a large list would impact RPC transfer?

My understanding is:

  • We should aim to keep individual RPC messages small (≈1 - 2 MiB).
  • gRPC’s default (hashicorp) max message size is about 4 MiB; larger messages can hurt latency or even fail unless limits are increased.

hashicorp/go-plugin doesn’t provide automatic chunking.

FYI: we should be careful with RPC message sizes. If we approach these limits, migrating the interface to gRPC should be our first step.

…side

- to filter relevant issues by bofy-filter, and don't send not relevant items over RPC
- Introduced `BodyFilter` parameter in `VCSListIssuesRequest` to filter issues based on body content.
- Implemented `filterIssuesByBody` function to handle substring matching for issue bodies.
- Updated `ListIssues` method to apply the body filter if provided, enhancing issue retrieval based on specific criteria.
- Added unit tests for body filtering functionality to ensure correct behavior.
@japroc japroc requested a review from shikari-ac November 2, 2025 09:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants