Allows the multi-module build to exploit testcontainer reuse by centralizing the setup and table truncation logic in a separate module.
With this change, migrations only run for the first module, once, in a full test suite run. Instead of each module booting its own testcontainer, they all use the same instance, provided reuse is enabled (which it is in CI).
Also removes code duplication caused by repeated testcontainers setup logic.
Signed-off-by: nscuro <nscuro@protonmail.com>
* Replaces all remaining `hyades-*` references with the canonical `dependency-track`.
* Resets version from `5.7.0-alpha.10-SNAPSHOT` to `5.0.0-rc.1-SNAPSHOT`.
* Updates README to mention that v5 is not yet GA, and where to find v4.
* Updates the defect report issue template to reflect the major version split.
* Selfishly lists myself as developer in the Maven POM.
Signed-off-by: nscuro <nscuro@protonmail.com>
We no longer have a case where only a single extension of a given extension point is requested, so the concept of default extensions is no longer useful.
Similarly, required extensions are no longer a thing. All extension points we have can handle 0..N extensions.
This simplifies the plugin API by dropping baggage we don't need.
Signed-off-by: nscuro <nscuro@protonmail.com>
Raises the Java baseline from 21 to 25, and leverages new language features:
* Replaces the various "ignored" and "ignoredMdc" variables with `_`.
* Replaces hand-rolled batching / partitioning logic with `windowFixed(n)` stream gatherers.
Note that we already shipped with a Java 25 base image for a long while, so there are no runtime-related changes.
Signed-off-by: nscuro <nscuro@protonmail.com>
Since we're going to re-version to 5.0.0 as part of the GA cut-over, it would be confusing if code comments such as `@since` Javadoc tags refer to higher versions.
Signed-off-by: nscuro <nscuro@protonmail.com>
Verified manually that the schema produced by the Flyway baseline match the schema produced by Liquibase. No point in adding an automated test for this.
Also verified that an instance with existing Liquibase schema migrates cleanly to Flyway, including removal of Liquibase's `databasechangelog` and `databasechangeloglock` tables.
To compensate for the removal of the Liquibase Maven plugin, a new `migrate` command has been added to the apiserver CLI. As a side effect, this now allows users without a full development setup to generate SQL migration files.
Signed-off-by: nscuro <nscuro@protonmail.com>
This was originally necessary because `FileStorage` was an extension point, and it didn't make sense to load the s3 provider when only the local provider was used. We have since moved all infra-level concerns *away* from the extension mechanism, so this use-case no longer exists.
Once we add support for loading extensions from external plugins, we'll need a similar mechanism, but most likely one with opt-in rather than opt-out semantics (i.e. operators decide explicitly what to load).
Until then, this toggle only adds unnecessary config surface.
Signed-off-by: nscuro <nscuro@protonmail.com>
* Decouples runtime configuration and testing from the ExtensionFactory interface into separate RuntimeConfigurable and Testable interfaces.
* Replace ExtensionContext with a more generic ServiceRegistry, which will be easier to extend going forward.
* Improve naming of various classes, e.g. ExtensionKVStore -> KeyValueStore.
* Updates the extensions REST API to indicate whether a given extension supports runtime configuration or testing.
* Aligns response of extension list endpoints with others in the API.
Signed-off-by: nscuro <nscuro@protonmail.com>
Since the plugin infrastructure around `PluginManager` is fairly self-contained, it should not live in the apiserver module, which is already quite large.
This extracts the plugin infra and moves it to a dedicated plugin-runtime module. This also makes the code easier to discover for new contributors.
Signed-off-by: nscuro <nscuro@protonmail.com>
* Removes proto dependency from plugin-api.
* Move vuln data source API to separate module, similar to file-storage-api and notification-api.
This is necessary to retain clear responsibilities and avoid circular module dependencies.
Signed-off-by: nscuro <nscuro@protonmail.com>
After extensive testing and some initial user feedback, it became clear that expressions / templating provides horrible UX, because:
* It's not clear where expressions can be used.
* Expressions are only evaluated at runtime, so users don't get feedback when they reference secrets that don't exist.
* Non-technical users struggle with expression syntax.
Additionally, we don't really *need* the flexibility expressions give us. We just need a way to safely reference managed secrets.
This change introduces support for the `x-secret-ref` JSON schema annotation. Properties annotated with it will be treated as secret references.
When extensions retrieve their runtime config, secret references are transparently resolved.
When extension configs are updated via REST API, it's validated that all referenced secrets exist.
Secret managers now support pagination and filtering for the `listSecrets` operation. This is used to deliver a convenient dropdown with search-as-you-type in the UI. Note that it is expected that not all providers can support pagination natively, in which case they'll need to emulate the desired behaviour, which is what the `env` provider does.
Listing secret metadata no longer requires the `SECRET_MANAGEMENT_READ` permission, but the `SYSTEM_CONFIGURATION_READ` permission. This is because users who maintain configuration are actually the ones that need to know which secrets they can use.
Signed-off-by: nscuro <nscuro@protonmail.com>
