Skip to content

Source the server and OpenVoxDB component tables from SBOMs#377

Open
miharp wants to merge 1 commit into
OpenVoxProject:masterfrom
miharp:docs/sbom-server-tables-363
Open

Source the server and OpenVoxDB component tables from SBOMs#377
miharp wants to merge 1 commit into
OpenVoxProject:masterfrom
miharp:docs/sbom-server-tables-363

Conversation

@miharp

@miharp miharp commented Jun 29, 2026

Copy link
Copy Markdown
Contributor

What

Migrates the server and OpenVoxDB component-versions tables to the
SbomReleaseTable base, completing the openvox-sbom-tools
adoption started in #366 (which moved the agent and OpenBolt tables). Both packages
now publish SBOMs covering the tables' 8.12.0 floor, so the old pin scraping can go.

Closes #363.

Changes

openvox-server

Reads the bundled JRuby from the SBOM's jruby-base component instead of resolving
it through the server's pinned jruby-utilsjruby-deps in project.clj.
jruby-base is already the clean resolved version, so this also drops the -N
packaging-suffix strip the old path needed. Values are unchanged for the
existing rows (all JRuby 9.4.12.1); the regen additionally picks up the 8.14.1
release the stale data was missing.

openvoxdb

OpenVoxDB is a Clojure/JVM service with no bundled JRuby, so rather than leave it
as the one tag-only table, it gains a Jetty column (the embedded HTTP server)
sourced from the SBOM's jetty-server component — which shows a real
10.0.2612.1.10 bump at 8.14.0. A Java column is added as a
hand-maintained supported-version requirement to match the server table, and
PostgreSQL stays a hand-maintained requirement.

OpenVoxDB release Jetty Java PostgreSQL
8.14.1 12.1.10 17, 21 11+ (14+ recommended)
8.14.0 12.1.10 17, 21 11+ (14+ recommended)
8.13.0 10.0.26 17, 21 11+ (14+ recommended)

Note: the postgresql 42.7.11 in the SBOM is the JDBC driver, not the database
server — so the PostgreSQL column remains the hand-maintained server-version
requirement, not a SBOM value.

Result

No puppet-runtime / project.clj scraping remains anywhere — every
component-versions table is now sourced from the per-release SBOMs. Page prose
describing the server and OpenVoxDB columns is updated to match.

Validation

  • rake rubocop clean; jekyll build succeeds.
  • Regenerated _data for both tables; server values verified identical to the prior
    committed data, OpenVoxDB Jetty values spot-checked against each release's SBOM.
  • Both tables confirmed rendering correctly in the built page.

Screenshots

Server table — JRuby unchanged, now picks up the 8.14.1 release:

sbom_server_table

OpenVoxDB table — new Jetty (SBOM) / Java / PostgreSQL columns, with the real
Jetty 10.0.26 → 12.1.10 bump at 8.14.0:

sbom_openvoxdb_table

@miharp miharp requested a review from a team as a code owner June 29, 2026 17:25
Comment thread docs/_openvox_8x/component_versions.md Outdated

| OpenVoxDB release | Jetty | Java | PostgreSQL |
| --- | --- | --- | --- |
{% for r in site.data.openvoxdb_release_contents[nav_key] %}| {{ r.release }} | {{ r.jetty }} | 17, 21 | 11+ (14+ recommended) |

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Todo for future us: we don't know the oldest working version. We currently only test postgresql 16 to 18 because the rest is ancient. https://github.com/OpenVoxProject/openvoxdb/blob/8.x/.github/workflows/main.yml#L51. Maybe it makes sense to refactor the version list into a json file in shared-actions.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good call — tracked in #378 (both the PostgreSQL-range verification and the idea of sourcing these ranges from a shared-actions JSON, like the supported-platforms page does). Left this PR as-is since it's non-blocking.

@miharp miharp force-pushed the docs/sbom-server-tables-363 branch 2 times, most recently from 48aeff6 to 59bba02 Compare June 29, 2026 17:36
Migrate the last two component-versions tables to the SbomReleaseTable base,
completing the openvox-sbom-tools adoption (the agent and OpenBolt tables moved
in OpenVoxProject#366). Both packages now publish SBOMs covering the 8.12.0 table floor.

- openvox-server: read the bundled JRuby from the SBOM's `jruby-base` component
  instead of resolving it through the pinned jruby-utils -> jruby-deps in
  project.clj. `jruby-base` is already the clean resolved version, dropping the
  "-N" packaging-suffix strip the old path needed. Values are unchanged for the
  existing rows (all JRuby 9.4.12.1); the regen also picks up the 8.14.1 release.
- openvoxdb: it is a Clojure/JVM service with no bundled JRuby, so the table gains
  a Jetty column (the embedded HTTP server) sourced from the SBOM's `jetty-server`
  component, which shows a real 10.0.26 -> 12.1.10 bump at 8.14.0. Java is added as
  a hand-maintained supported-version requirement to match the server table;
  PostgreSQL stays a hand-maintained requirement.

No puppet-runtime / project.clj scraping remains; every component-versions table is
now SBOM-sourced. Page prose describing the server and OpenVoxDB columns is updated.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Michael Harp <mike@mikeharp.com>
@miharp miharp force-pushed the docs/sbom-server-tables-363 branch from 59bba02 to f6e4d1e Compare June 29, 2026 18:02
@miharp miharp requested a review from bastelfreak June 30, 2026 09:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Generate Component Versions tables from openvox-sbom-tools

2 participants