Select Git revision
-
Jamie Tanna authored
As noted in #525, if you have run: dmd [...] import renovate [...] dmd [...] db generate dependency-health You will receive a single entry per dependency in `dependency_health` i.e.: github.com/google/uuid gomod 5.012345678903459 # stale Then, if you were to manually scan the repo with `scorecard` and import that data in with: dmd [...] import scorecard [...] This then results in multiple entries in `dependency_health` i.e.: github.com/google/uuid gomod 5.012345678903459 # stale github.com/google/uuid golang 7.099999904632568 # newer Then, when looking at the advisories that are present, or `JOIN`ing the tables, we will receive the stale data. To fix this, we can instead store, and solely use, the `package_type`, which we've derived. This was already what we were doing, just without the intermediate step of storing the `package_type` in the database. One area this could cause concern is if the version of `dmd` used to create the database + import data is different to the version then used to generate dependency health / to import the scorecards, and there may be a difference between the derived data in the database. However, this is fairly non-standard. This is a breaking change due to the definition in https://dmd.tanna.dev/concepts/compatible-since/: > Renaming of a column In which we've renamed the `package_manager` to `package_type`, so need to appropriately note that this is a breaking change. Closes #525, and a step towards #446.
Jamie Tanna authoredAs noted in #525, if you have run: dmd [...] import renovate [...] dmd [...] db generate dependency-health You will receive a single entry per dependency in `dependency_health` i.e.: github.com/google/uuid gomod 5.012345678903459 # stale Then, if you were to manually scan the repo with `scorecard` and import that data in with: dmd [...] import scorecard [...] This then results in multiple entries in `dependency_health` i.e.: github.com/google/uuid gomod 5.012345678903459 # stale github.com/google/uuid golang 7.099999904632568 # newer Then, when looking at the advisories that are present, or `JOIN`ing the tables, we will receive the stale data. To fix this, we can instead store, and solely use, the `package_type`, which we've derived. This was already what we were doing, just without the intermediate step of storing the `package_type` in the database. One area this could cause concern is if the version of `dmd` used to create the database + import data is different to the version then used to generate dependency health / to import the scorecards, and there may be a difference between the derived data in the database. However, this is fairly non-standard. This is a breaking change due to the definition in https://dmd.tanna.dev/concepts/compatible-since/: > Renaming of a column In which we've renamed the `package_manager` to `package_type`, so need to appropriately note that this is a breaking change. Closes #525, and a step towards #446.
Code owners
Assign users and groups as approvers for specific file changes. Learn more.
queries.sql.go 13.88 KiB