| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
|
Somehow one of the Node packages in main had managed to get out of sync with that the lockfile specified. This should be impossible due to the PR checks so I'm not quite sure how that happened. Anyway, I've pushed an additional commit to this PR to address that (probably no need to do it in a separate PR?). |
Sorry, something went wrong.
|
I've confirmed that this change gives the expected result in a test repository: "metricResults": [
{
"rule": {
"toolComponent": {
"index": 22
},
"index": 70,
"id": "js/summary/lines-of-code"
},
"ruleId": "js/summary/lines-of-code",
"baseline": 3,
"value": 3
},
{
"rule": {
"toolComponent": {
"index": 22
},
"index": 71,
"id": "js/summary/lines-of-user-code"
},
"ruleId": "js/summary/lines-of-user-code",
"baseline": 3,
"value": 3
}
], |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
This PR updates the code that injects the baseline LOC count into the SARIF results to also inject it into any metricResult that references a rule which has the lines-of-code tag. This is the location that newer versions of Code Scanning will expect to find the LOC count. The old style (injecting into the metricResult with suffix /summary/lines-of-code) is also retained for backwards compatibility, but we should be able to remove this eventually.
I don't think we need a changelog entry as this change shouldn't really affect any users (unless they are manually uploading the SARIF to a non-Code Scanning endpoint, which I'm not sure is a scenario we support).
Merge / deployment checklist