Jamie Tanna authored 1 year ago and Jamie Tanna committed 1 year ago

As part of #258, we can introduce the `policy evaluate` command to give
an indication of the impact of a given Policy being introduced.

This requires we:

- list all the repos and packages (so we can perform per-repo tuning of
  policies if needed) from Renovate and SBOM datasources
- evaluate the policy, across many Goroutines due to the expected size
  of the returned list of dependencies

Although the scope of #273 was for this to be a `--dry-run` flag, it
makes more sense to be by default.

Closes #273.

Tanna[bot] authored 1 year ago and Jamie Tanna committed 1 year ago

And moving to my fork due to
https://github.com/sqlc-dev/sqlc/issues/2729.

Also requires updating the project name since the rename.

Jamie Tanna authored 1 year ago and Jamie Tanna committed 1 year ago

As a way to provide a better means to annotate certain dependencies with
information about why the package(s), or certain versions of a package
must not be used, we can introduce the concept of Advisories.

This produces a new table, `advisories`, that can be used to insert
arbitrary advisories for package, such as "this package is no longer
maintained" or "don't use this because of a security vulnerability".

We can add a `db generate advisory` subcommand which can pre-seed with
some community-provided package advisories, as an example of what can be
done.

We can use a more complicated query to perform this lookup using a
`case / when` which allows us to perform more logic inside our query to
look up the data, instead of performing the lookup in Go code.

This uses an enum-style approach inside the database schema to provide a
bit more control over the entries, as this is more likely to have custom
SQL executed against it, so we want to make sure that we're not
going to end up with out-of-sync data.

Unfortunately sqlc seems to be unhappy when using multiple `INSERT`s, so
we need to execute the query manually.

Closes #45.

It's handy to be able to use the AWS ElastiCache data in an SQLite format, and
works well to sit under this project.

The logic and management of the dates that runtimes are deprecated by
remains in endoflife-checker so it can remain its own standalone library.

It's handy to be able to use the AWS Lambda data in an SQLite format,
and works well to sit under this project.

The logic and management of the dates that runtimes are deprecated by
remains in endoflife-checker so it can remain its own standalone library.

To simplify onboarding and the structure, rather than having a lot of
top-level packages we can put them under `datasources`.

This also refactors the `db init` command to use a consistent interface
for creation of tables, rather than it being done in the command itself.

Although the data isn't nearly as right as Renovate, it's handy to have
both datasources available.

Closes #6.

As part of the longer piece of work to introduce a suite of tools for
managing dependency-management-data, we're starting with the commands to
bootstrap a DMD SQLite database.

This mirrors the `filter.rb` from renovate-graph with some additional
data points we've found useful at Deliveroo.

We use sqlc to make it nicer to interact with our database in a strongly
typed fashion.

As it doesn't support migrations - and we're not yet at the point we need
migrations - we can simply just run the `CREATE ...` steps.

Closes #2