1. Dependency Management Data
  2. Changelog

Changelog

0.115.0 (2024-12-19)

📣 Breaking Changes


When using the SBOM exported by `renovate-to-sbom` with other tools,
some pieces of data are not useful when they are i.e. a range of
versions.

Instead of this, we can - by default - ignore anything that doesn't have
a resolved `CurrentVersion` as it's likely that the exact version will
not be present.

This is a breaking change as we change the behaviour of the command.

We can introduce a flag to re-enable the functionality, as well as
document the fact that this may cause false positives.

As this is not a breaking change in dependency-management-data itself,
we will not bump `compatible_since`.

🚧 Chores

0.114.0 (2024-12-19)

📣 Breaking Changes


When deriving the underlying `package_name` for the Renovate datasource,
we've been using `depName` from the underlying package data exports.

For most cases, this gives us exactly what we want, but in some cases,
this presents a different a different `package_name`, as the `depName`
is generally intended to be for the "pretty" name for a package.

For instance:

    {
      "depType": "plugin",
      "depName": "org.sonarqube",
      "packageName": "org.sonarqube:org.sonarqube.gradle.plugin",
      "currentValue": "3.3",
      "datasource": "maven",
      "packageScope": "org.sonarqube",
      "currentVersion": "3.3",
      "isSingleVersion": true,
      "fixedVersion": "3.3"
    }

To correct this, we can make sure we now prioritise `packageName`.

This requires a bump of `compatible_since`, as this is a change to the
way that the data is derived, and may incur breakages to existing users'
queries.

🚧 Chores

0.113.5 (2024-12-19)

🐞 Bug Fixes

🚧 Chores

0.113.4 (2024-12-13)

🐞 Bug Fixes

🚧 Chores

📦 Build

0.113.3 (2024-12-10)

🐞 Bug Fixes

🚧 Chores

0.113.2 (2024-12-10)

🐞 Bug Fixes

🚧 Chores

0.113.1 (2024-12-10)

🐞 Bug Fixes

🚧 Chores

0.113.0 (2024-12-09)

🎁 Feature

📄 Documentation

🚧 Chores

0.112.0 (2024-12-09)

🎁 Feature

🚧 Chores

0.111.1 (2024-12-09)

🐞 Bug Fixes

🚧 Chores

📦 Build

0.111.0 (2024-12-08)

🎁 Feature

📄 Documentation

🚧 Chores

0.110.2 (2024-11-29)

🐞 Bug Fixes

🚧 Chores

0.110.1 (2024-11-21)

🐞 Bug Fixes

🔀 Code Refactoring

🚧 Chores

0.110.0 (2024-11-18)

🎁 Feature

🐞 Bug Fixes

📈 Performance Improvements

📄 Documentation

🔀 Code Refactoring

🚧 Chores

📦 Build

0.109.0 (2024-11-12)

🎁 Feature

📄 Documentation

🚧 Chores

📦 Build

0.108.0 (2024-10-30)

📣 Breaking Changes


I've noticed that in some cases we're seeing HTTP 403s from Ecosystems,
which could be due to the sheer amount of traffic we're sending.

We should significantly reduce this number to avoid the risks of rate
limiting.

This is breaking, as it does introduce a significant increase in
processing time, albeit a very reasonable change to introduce.

Related to #459.

0.107.0 (2024-10-28)

🎁 Feature

📄 Documentation

🎨 Styles

0.106.1 (2024-10-19)

🐞 Bug Fixes

📦 Build

0.106.0 (2024-09-03)

🎁 Feature

0.105.0 (2024-09-01)

🎁 Feature

0.104.2 (2024-08-31)

🐞 Bug Fixes

📄 Documentation

🎨 Styles

📦 Build

0.104.1 (2024-08-25)

🐞 Bug Fixes

0.104.0 (2024-08-24)

🎁 Feature

📄 Documentation

0.103.0 (2024-07-28)

🎁 Feature

0.102.0 (2024-07-27)

🎁 Feature

🐞 Bug Fixes

📈 Performance Improvements

📄 Documentation

🔀 Code Refactoring

🚧 Chores

📦 Build

0.101.0 (2024-07-14)

🎁 Feature

📈 Performance Improvements

📄 Documentation

📦 Build

0.100.6 (2024-07-11)

🐞 Bug Fixes

📈 Performance Improvements

📄 Documentation

🚧 Chores

🔁 CI

0.100.5 (2024-07-08)

🐞 Bug Fixes

0.100.4 (2024-07-08)

🐞 Bug Fixes

🚧 Chores

0.100.3 (2024-07-08)

🐞 Bug Fixes

🚧 Chores

0.100.2 (2024-07-08)

🐞 Bug Fixes

0.100.1 (2024-07-08)

🐞 Bug Fixes

0.100.0 (2024-07-07)

📣 Breaking Changes


As part of #530, we want to make it possible to consume SBOMs without a
Repo Key, for instance if you've been provided an SBOM from a vendor, or
you're scanning a container image, which doesn't _necessarily_
correspond directly to a repository.

This performs a significant breakage, removing the Repo Key fields from
the `sboms` table, and instead requiring that the metadata be instead
stored in the `component_metadata` table and JOIN'd on the
`component_name` column.

This is a significant breaking change, so we mark this as a breaking
change, as well as bumping `compatible_since`.

This also:

- introduces a `path`, which provides a step towards #408 and better
  monorepo support
- involves fixing /a lot/ of queries that made assumptions about Repo
  Keys
- flags a number of places that will need to be improved in the future
  when we want to query for non-Repo Key results i.e. in advisories or
  other reports
- make it optional in `component_metadata`
- make it optional in `import sbom`
- introduce a better UX for Repo Key validation now it's optional when
  importing
- amending DB docs that reference the now-nonexistent `sboms.platform`
  (etc)
- making sure we pass through `sql.NullString`'s underlying `String` to
  `table.Row`s, otherwise we receive i.e. `{Example true}` which isn't
  helpful
- prioritise `component_metadata` over `owners` lookups, as the
  Component may have an owner but not a Repo Key (i.e. if it's vendor
  owned, or a Docker image)
- introduce a helper for UPSERTing, as it requires we check the row is
  already there (or so I think, I aimed to avoid #549)

Closes #530.

🎁 Feature

📄 Documentation

🚧 Chores

🔁 CI

0.99.0 (2024-07-02)

🎁 Feature

📈 Performance Improvements

📄 Documentation

🚧 Chores

0.98.1 (2024-06-30)

🐞 Bug Fixes

0.98.0 (2024-06-28)

🎁 Feature

🚧 Chores

0.97.1 (2024-06-14)

🐞 Bug Fixes

0.97.0 (2024-06-14)

🎁 Feature

📄 Documentation

🚧 Chores

0.96.0 (2024-06-05)

🎁 Feature

🐞 Bug Fixes

🚧 Chores

0.95.0 (2024-05-14)

📣 Breaking Changes


Right now, we're returning all the results of a given repository's
advisories, which can be extremely large if targeting a monorepo, or
just a repo with a lot of dependencies.

To prevent potentially retrieving and then sending hundreds or thousands
of results to the caller, we can instead set up pagination.

This uses offset-based pagination, but with an encoded cursor, mentioned
in [0] and seen across other APIs. We use offset-based pagination as we
don't have a stable identifier for a given row, and so it's easier to
think of it in terms of an offset.

To do so, we need to change the structure of our GraphQL response, which
allows us to surface pagination information.

We can also add an explicit `pageSize` limit in our schema, so it's
clearer to the user what the default behavior is.

However, this is a breaking change as we're changing the structure of
the GraphQL response, which needs to be flagged appropriately with a
`compatible_since` bump.

This requires that we use a named variable for sqlc for `limit` and
`offset`, otherwise we get errors such as:

    missing argument with index ...

Due to the rest of the query having numbered indexes generated by sqlc.

Closes #564.

[0]: https://betterprogramming.pub/understanding-the-offset-and-cursor-pagination-8ddc54d10d98

📄 Documentation

🔀 Code Refactoring

🚧 Chores

0.94.3 (2024-04-24)

🐞 Bug Fixes

0.94.2 (2024-04-24)

🐞 Bug Fixes

📄 Documentation

🔀 Code Refactoring

0.94.1 (2024-04-10)

🐞 Bug Fixes

0.94.0 (2024-04-09)

📣 Breaking Changes


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.

📄 Documentation

0.93.1 (2024-04-09)

🐞 Bug Fixes

0.93.0 (2024-04-09)

🎁 Feature

📄 Documentation

0.92.0 (2024-04-08)

📣 Breaking Changes


When importing SBOMs, we consume the Package URL (pURL) and take the
parts of it that we want to keep, but then throw away the rest.

Instead of doing this, we should make it available in the database,
where it can then be retrieved and further processed.

This allows us to take more complex pURLs like:

    pkg:rpm/redhat/xz-libs@5.2.4-4.el8_6?arch=x86_64&distro=redhat-8.6

    pkg:deb/debian/login@1:4.8.1-1?arch=arm64

And then we're able to perform more complex processing on them.

This is a breaking change due to the definition in
https://dmd.tanna.dev/concepts/compatible-since/:

> Introducing a required column, which doesn't have a default

In which we've added the `package_url` field, so need to appropriately
note that this is a breaking change.

This also requires refactoring the parameter to
`newSBOMDependenciesQuery` as it's no longer getting a full SBOM row, as
we don't query the `package_url`.

Closes #528.

📄 Documentation

0.91.0 (2024-04-07)

🎁 Feature

🐞 Bug Fixes

📄 Documentation

🚧 Chores

0.90.1 (2024-03-21)

🐞 Bug Fixes

📄 Documentation

0.90.0 (2024-03-06)

🎁 Feature

📄 Documentation

0.89.3 (2024-03-06)

🐞 Bug Fixes

0.89.2 (2024-03-06)

🐞 Bug Fixes

0.89.1 (2024-03-05)

🐞 Bug Fixes

📄 Documentation

🚧 Chores

0.89.0 (2024-02-22)

🎁 Feature

🐞 Bug Fixes

📄 Documentation

🚧 Chores

0.88.0 (2024-02-21)

🎁 Feature

📄 Documentation

0.87.0 (2024-02-20)

🎁 Feature

📄 Documentation

🔀 Code Refactoring

🚧 Chores

0.86.0 (2024-02-20)

📣 Breaking Changes


As noted in #470, the anonymisation feature may have been useful, but
has not been used.

Although we could keep the feature in, it is regularly _not_ being
implemented when new repositories are being created, so a user expecting
the feature to be available will be lulled into a false sense of
security.

Instead, we should remove the feature.

In `repositorymetadata` we need to still retain a single query, as
`sqlc` requires at least one query per schema.

Closes #470, #471, #306, #283, #274, #221, #165.

📄 Documentation

0.85.0 (2024-02-19)

📣 Breaking Changes


We first introduced `policy_violations` as a means to store data for the
Policy evaluations, and at the time we took the opportunity to include
more data in the table than was present previously.

Over time, we've seen that the new `advisories` (which replaced
`custom_advisories`) table is necessary to follow the same shape of
data, including pulling in data from each of the tables to provide a
single view of all advisories.

However, since we've made `advisories` use the same shape of data, it's
unreasonable to have both tables, when there's no purpose and it leads
to confusion.

As part of this, we can also close off some subtle implementation bugs
that were due to the complexity of the two tables having a fair bit of
overlap.

This was largely due to the way that we were allowed to use non-`POLICY`
advisory types, so lookups across tables were a little awkward.

Closes #452, #298, #400, #340.

0.84.0 (2024-02-19)

🎁 Feature

📄 Documentation

0.83.0 (2024-02-16)

🎁 Feature

📈 Performance Improvements

📄 Documentation

🔀 Code Refactoring

🚧 Chores

📦 Build

0.82.2 (2024-02-08)

🐞 Bug Fixes

0.82.1 (2024-02-08)

🐞 Bug Fixes

0.82.0 (2024-02-08)

🎁 Feature

🐞 Bug Fixes

📄 Documentation

🔀 Code Refactoring

🚧 Chores

📦 Build

0.81.0 (2024-02-08)

📣 Breaking Changes


This is a breaking change as consumers who are pinning their versions of
Go will break.

📄 Documentation

🚧 Chores

0.80.2 (2024-02-05)

🐞 Bug Fixes

📄 Documentation

🚧 Chores

0.80.1 (2024-02-01)

🐞 Bug Fixes

0.80.0 (2024-02-01)

📣 Breaking Changes


As noted in #387, the advisories and policy violations reports are
likely to load a very large number of rows.

Instead of loading them by default, we can instead require a querystring
parameter to enforce this.

This allows us to still render the pages with all the data - at our own
risk - but the default nudges towards limiting this down.

This is a breaking change due to the expectation that a bookmarked URL
would still result in the same data.

Closes #387.


As noted in #199, it isn't the best experience if you don't have any (AWS)
infrastructure imported, and can be confusing.

This should be done for both the web and CLI reports.

This is a breaking change due to moving of data from where it was
previously expected.

Closes #199.

🎁 Feature

🐞 Bug Fixes

📄 Documentation

🚧 Chores

📦 Build

0.79.0 (2024-01-31)

🎁 Feature

📄 Documentation

0.78.0 (2024-01-30)

🎁 Feature

0.77.0 (2024-01-30)

🎁 Feature

📄 Documentation

0.76.0 (2024-01-27)

🎁 Feature

📄 Documentation

🔀 Code Refactoring

🚧 Chores

0.75.2 (2024-01-26)

🐞 Bug Fixes

📈 Performance Improvements

📄 Documentation

🔀 Code Refactoring

🚧 Chores

0.75.1 (2024-01-23)

🐞 Bug Fixes

📦 Build

0.75.0 (2024-01-22)

🎁 Feature

📄 Documentation

0.74.0 (2024-01-21)

🎁 Feature

📄 Documentation

0.73.0 (2024-01-18)

📣 Breaking Changes


The Dependabot-specific tables have been deprecated for some time, so we
should remove them to clean things up.

This could be a breaking change for anyone still relying on them, but
there's been no data imported into these tables since before v0.38.0, so
I'd be surprised if it did break anything.

Closes #168.

📄 Documentation

🔀 Code Refactoring

🚧 Chores

📦 Build

0.72.0 (2024-01-18)

📣 Breaking Changes


It's been deprecated officially for a week or so, but hasn't been
actually wired into Advisories, as we've had deps.dev's data which is
superior.

By removing this, we'll also hopefully reduce the time it takes folks to
build their databases, as osv.dev lookups were fairly slow.

📄 Documentation

📦 Build

0.71.1 (2024-01-17)

🐞 Bug Fixes

🚧 Chores

📦 Build

0.71.0 (2024-01-16)

📣 Breaking Changes


BREAKING CHANGE:

For some time, I've regretted the naming choice, as it can be a little
confusing because the `advisories` table doesn't include all the
advisories present in the dependency trees.

This now makes it more explicit by using the new name
`custom_advisories`.

🎁 Feature

📄 Documentation

🔀 Code Refactoring

0.70.0 (2024-01-16)

📣 Breaking Changes


This has been accidentally misaligned for some time, and will cause some
confusion when querying the data.

To keep this more consistent, we should make sure we return a known
`advisory_type`.

📄 Documentation

0.69.0 (2024-01-16)

🎁 Feature

0.68.0 (2024-01-16)

🎁 Feature

📄 Documentation

0.67.1 (2024-01-15)

🐞 Bug Fixes

0.67.0 (2024-01-12)

🎁 Feature

🐞 Bug Fixes

📄 Documentation

0.66.0 (2024-01-09)

📣 Breaking Changes


To allow for us to make it possible to expose both the owner's name and
notes, we should refactor this into an `Owner` object, rather than a
plain string.

This requires a bit of wiring in for the different queries that use the
field, as well as making sure it gets resolved.

0.65.2 (2024-01-08)

🐞 Bug Fixes

📄 Documentation

🔀 Code Refactoring

🚧 Chores

0.65.1 (2024-01-04)

🐞 Bug Fixes

📄 Documentation

📦 Build

0.65.0 (2023-12-22)

🎁 Feature

📄 Documentation

0.64.1 (2023-12-22)

🐞 Bug Fixes

📦 Build

v0.64.0 (2023-12-22)

v0.63.1 (2023-12-19)

v0.63.0 (2023-12-17)

v0.62.0 (2023-12-11)

v0.61.0 (2023-12-07)

v0.60.0 (2023-11-29)

v0.59.0 (2023-11-29)

v0.58.0 (2023-11-28)

v0.57.0 (2023-11-27)

Breaking change

v0.56.0 (2023-11-27)

v0.55.0 (2023-11-25)

v0.54.0 (2023-11-24)

Breaking changes

v0.53.0 (2023-11-20)

v0.52.9 (2023-11-19)

v0.52.8 (2023-11-19)

v0.52.7 (2023-11-16)

v0.52.6 (2023-11-16)

v0.52.5 (2023-11-15)

v0.52.4 (2023-11-07)

v0.52.3 (2023-11-07)

v0.52.2 (2023-11-07)

v0.52.1 (2023-11-05)

v0.52.0 (2023-11-03)

v0.51.0 (2023-10-30)

v0.50.0 (2023-10-30)

v0.49.0 (2023-10-29)

v0.48.0 (2023-10-26)

v0.47.0 (2023-10-25)

v0.46.0 (2023-09-24)

v0.45.0 (2023-09-23)

v0.44.2 (2023-09-23)

v0.44.1 (2023-09-23)

v0.44.0 (2023-09-23)

v0.43.0 (2023-09-20)

v0.42.2 (2023-09-20)

v0.42.1 (2023-09-20)

v0.42.0 (2023-09-19)

v0.41.0 (2023-09-12)

v0.40.0 (2023-09-11)

v0.39.0 (2023-09-10)

v0.38.0 (2023-09-10)

v0.37.0 (2023-08-29)

v0.36.2 (2023-07-29)

v0.36.1 (2023-07-24)

v0.36.0 (2023-07-21)

v0.35.0 (2023-07-21)

v0.34.0 (2023-07-18)

v0.33.0 (2023-07-15)

v0.32.0 (2023-07-13)

v0.31.1 (2023-07-09)

v0.31.0 (2023-07-08)

v0.30.1 (2023-07-03)

v0.30.0 (2023-06-29)

v0.29.0 (2023-06-21)

v0.28.0 (2023-06-21)

v0.27.0 (2023-06-18)

v0.26.0 (2023-06-16)

v0.25.1 (2023-06-07)

v0.23.1 (2023-06-07)

v0.25.0 (2023-06-07)

v0.24.0 (2023-05-29)

v0.23.0 (2023-05-29)

v0.22.1 (2023-05-27)

v0.22.0 (2023-05-21)

v0.21.0 (2023-05-20)

v0.20.3 (2023-05-15)

v0.20.2 (2023-05-15)

v0.20.1 (2023-05-09)

v0.20.0 (2023-04-18)

v0.19.0 (2023-04-14)

v0.18.1 (2023-04-11)

v0.18.0 (2023-04-10)

v0.17.0 (2023-04-08)

v0.16.0 (2023-04-05)

v0.15.1 (2023-04-04)

v0.15.0 (2023-04-03)

v0.14.0 (2023-04-02)

v0.13.0 (2023-03-27)

v0.12.0 (2023-03-21)

v0.11.1 (2023-03-20)

v0.11.0 (2023-03-19)

v0.10.0 (2023-03-18)

v0.9.0 (2023-03-18)

v0.8.0 (2023-03-18)

v0.7.0 (2023-03-16)

v0.6.2 (2023-03-16)

v0.6.1 (2023-03-16)

v0.6.0 (2023-03-15)

v0.5.0 (2023-03-15)

v0.4.1 (2023-03-05)

v0.4.0 (2023-03-04)

v0.3.3 (2023-02-27)

v0.3.2 (2023-02-25)

v0.3.1 (2023-02-21)

v0.3.0 (2023-02-20)

v0.2.0 (2023-02-20)

v0.1.0 (2023-02-16)