Provide log deconstruction mechanism that leverages file names #211
Labels
Comments
|
Yes, as we discussed on the phone: We would search for an element such as "run.files" in the following order:
|
|
@michaelcfanning As we discussed on the phone, this "configuration by convention" is an unnecessary complication. It also burdens consumers to probe for a conventionally named file -- which frequently won't be there -- whenever an optional, "externalizable" property is missing from a log file. Without the configuration by convention feature, the lookup is the same as in my comment above, but without Step 3. Closing this issue. |
ghost
closed this as This issue was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Consider a file named MyOutput.sarif. On opening this file, a consumer could search for MyOutput.files.sarif in order to locate a 'files' table that is associated with MyOutput.sarif.
This approach would prevent the need to have SARIF properties have two types (either a URI or the property itself). We might to consider a mechanism to allow retrieving this content from the web.
Merging this idea with #210, we could also simply consider allowing the 'master' file to include a set of URLs to consult for populating the data rather than inlining the URLs:
indirectSarifDataSources
{
"files" : [ { "file:///e:/MySarif.files.sarif"}
}
The text was updated successfully, but these errors were encountered: