-
Notifications
You must be signed in to change notification settings - Fork 9
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
Include new app_blocking_match_based_ids
field in ci_scan_complete_response
#326
Conversation
Backwards compatibility summary:
|
Sorry, going to leave some high-level feedback here since I don't have context on the project. Feel free to ping me in Slack or put time on my calendar if you want to discuss in person: How would we know ahead of time which match_based_id's are blocking? We don't know a match_based_id for a particular finding until we've seen that finding at least once - and we don't know the various qualities of that finding until it's been detected at least once, so don't know whether or not to block on it. Seems like a chicken and egg problem, but maybe I'm missing something? EDIT: I now realize this is part of the |
Discussed this with @chmccreery on a call, we got the go ahead |
Right now whether or not a CI scan should exit with code 1 is determined mostly by the CLI, but the app can use the
app_block_override
field ofci_scan_complete_response
to tell the CLI to exit with code 1 no matter what. This is currently used to support blocking scans when we detect a dependency with a blocked license.We're currently working on a project which includes making it more customizable within the app whether or not a given finding should be blocking, right now just for supply chain, but with the aim to eventually move the computation of blocking findings entirely to the app. So we'd like to be able to tell the CLI not only "please block" but also "here are the list of findings that the app determined are blocking".
make setup && make
to update the generated code after editing a.atd
file (TODO: have a CI check)For example, the Semgrep backend need to still be able to consume data
generated by Semgrep 1.50.0.
See https://atd.readthedocs.io/en/latest/atdgen-tutorial.html#smooth-protocol-upgrades
Note that the types related to the semgrep-core JSON output or the
semgrep-core RPC do not need to be backward compatible!