Stretch Goals
Relevant links
Code for linter cmd is https://github.com/ossf/osv-schema/tree/main/tools/osv-linter linter tool
Linter Frontend: https://github.com/google/osv.dev/tree/master/gcp/website/frontend3/src
Linter findings worker: https://github.com/google/osv.dev/tree/master/go/cmd/osv-linter-worker
API: server.py (soon changing) #L364
Public Import Finding: gs://osv-test-public-import-logs/linter-result
Cron Job: https://github.com/google/osv.dev/blob/master/deployment/clouddeploy/gke-workers/environments/oss-vdb-test/osv-linter.yaml
For 1 (Remove withdrawn records from linter checks) - We generally don't care about the linting status of withdrawn records, so we don't want to see any alerts on these. I believe these changes will likely need to happen at the osv-schema linter level, as it operates in bulk and is the only point in which the records are actually read. If we want to keep the withdrawn records and filter them out later, this is also doable but would need to parse the record and filter in the browser - which seems like a lot of wasted work.
2 (Fix the bad padding on the right hand side), this should align:
3 (Make the data viewer have json syntax highlighting and collapsible behaviour), similar logic is already in the triage.js logic to make this work. Basically, I want to be able to hide sections if they aren't useful to triage issues.
4 (Make the linter worker operate on prod records as well) - Currently the linter only operates on the test records, but as these are sometimes differing from prod records, it'd be great to have an instance running these checks on prod. This is more involved, as it'd need another Datastore/bucket for prod, and rejigging part of the frontend.
5 (Loading of the frontend is slow) There's a lot of room for improvement for how the linter page is loaded. There's currently a bug that if you click a record too fast before it is all loaded, it will only show 'no findings for this record' and you have to reload the page in order to see it.
6. Highlight linting error in the frontend - It would be really helpful to have a way of highlighting the actual components that the linting error is referring to.
7. Better filtering - It would be nice with some filtering like being able to select multiple databases or finding types instead of one or all.
8. Highlight differences between records in the prod vs test instance. Very much a nice-to-have but somehow highlighting differences between the prod and test instance linter findings could be interesting information - I'm not entirely sure how this would be displayed though.
9. Connect CVE records directly with the triage page. We have another tool behind auth for specifically triaging CVE based records. It would be nice to have a link on CVE linter error pages that opens the triage page with that CVE record preloaded - /triage?id=CVE-2024-3094
Stretch Goals
Relevant links
Code for linter cmd is https://github.com/ossf/osv-schema/tree/main/tools/osv-linter linter tool
Linter Frontend: https://github.com/google/osv.dev/tree/master/gcp/website/frontend3/src
Linter findings worker: https://github.com/google/osv.dev/tree/master/go/cmd/osv-linter-worker
API: server.py (soon changing) #L364
Public Import Finding: gs://osv-test-public-import-logs/linter-result
Cron Job: https://github.com/google/osv.dev/blob/master/deployment/clouddeploy/gke-workers/environments/oss-vdb-test/osv-linter.yaml
For 1 (Remove withdrawn records from linter checks) - We generally don't care about the linting status of withdrawn records, so we don't want to see any alerts on these. I believe these changes will likely need to happen at the osv-schema linter level, as it operates in bulk and is the only point in which the records are actually read. If we want to keep the withdrawn records and filter them out later, this is also doable but would need to parse the record and filter in the browser - which seems like a lot of wasted work.
2 (Fix the bad padding on the right hand side), this should align:
3 (Make the data viewer have json syntax highlighting and collapsible behaviour), similar logic is already in the triage.js logic to make this work. Basically, I want to be able to hide sections if they aren't useful to triage issues.
4 (Make the linter worker operate on prod records as well) - Currently the linter only operates on the test records, but as these are sometimes differing from prod records, it'd be great to have an instance running these checks on prod. This is more involved, as it'd need another Datastore/bucket for prod, and rejigging part of the frontend.
5 (Loading of the frontend is slow) There's a lot of room for improvement for how the linter page is loaded. There's currently a bug that if you click a record too fast before it is all loaded, it will only show 'no findings for this record' and you have to reload the page in order to see it.
6. Highlight linting error in the frontend - It would be really helpful to have a way of highlighting the actual components that the linting error is referring to.
7. Better filtering - It would be nice with some filtering like being able to select multiple databases or finding types instead of one or all.
8. Highlight differences between records in the prod vs test instance. Very much a nice-to-have but somehow highlighting differences between the prod and test instance linter findings could be interesting information - I'm not entirely sure how this would be displayed though.
9. Connect CVE records directly with the triage page. We have another tool behind auth for specifically triaging CVE based records. It would be nice to have a link on CVE linter error pages that opens the triage page with that CVE record preloaded - /triage?id=CVE-2024-3094