Skip to content
Snippets Groups Projects
Select Git revision
  • renovate/major-opa
  • spike/go-tools-124-gql
  • spike/go-tools-124
  • main default protected
  • chore/deepmap
  • docs/mas
  • build/notify
  • fix/du
  • defect/diff
  • defect/json
  • chore/schema
  • feat/diff-json
  • chore/typo
  • build/binaries
  • build/changelog-
  • defect/otel
  • chore/otel
  • chore/dep
  • docs/changelog
  • defect/changelog
  • v0.115.3 protected
  • v0.115.2 protected
  • v0.115.1 protected
  • v0.115.0 protected
  • v0.114.0 protected
  • v0.113.5 protected
  • v0.113.4 protected
  • v0.113.3 protected
  • v0.113.2 protected
  • v0.113.1 protected
  • v0.113.0 protected
  • v0.112.0 protected
  • v0.111.1 protected
  • v0.111.0 protected
  • v0.110.2 protected
  • v0.110.1 protected
  • v0.110.0 protected
  • v0.109.0 protected
  • v0.108.0 protected
  • v0.107.0 protected
40 results

queries.sql.go

  • Jamie Tanna's avatar
    06075fa0
    fix(scorecards)!: correctly override Renovate-driven results on import · 06075fa0
    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.
    06075fa0
    History
    fix(scorecards)!: correctly override Renovate-driven results on import
    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.
Code owners
Assign users and groups as approvers for specific file changes. Learn more.
queries.sql.go 13.88 KiB