Move release metadata from BigQuery to PostgreSQL

[mstaeble]

Summary

• Creates a release_definitions table in PostgreSQL to store release metadata (GA dates, development start dates, previous release, capabilities, product, status) previously only available in BigQuery
• Adds a release-definitions loader (--loader release-definitions) that fetches release rows from BQ and syncs them to PostgreSQL during the data load cycle
• /api/releases and the PG data provider now read from the release_definitions table instead of BigQuery or the hardcoded releaseMetadata map
• getReleases() in the server prefers PG, falls back to BQ
• Seeds release definitions for the dev database
• 9 files changed, +297/-80

A follow-up PR will replace v1.Release with models.ReleaseDefinition across all internal consumers, remove QueryReleases/QueryReleaseDates from the DataProvider interface, and eliminate the remaining BQ release functions.

Test plan

• go build ./... passes
• go vet ./... passes
• make lint passes
• go test ./pkg/... ./cmd/... passes
• sippy serve with seed data serves /api/releases from PostgreSQL with correct GA dates, capabilities, and previous release chain

Staging verification

Deployed the branch to sippy-staging and ran the release-definitions loader as a one-off job:

sippy load --loader release-definitions --init-database

Synced 36 release definitions from BigQuery to staging PostgreSQL (all OCP releases 3.11 through 5.0, OKD, ROSA, ARO, HyperShift, and CAPI entries).

Verified the following endpoints on sippy-staging.dptools.openshift.org:

Endpoint	Result
GET /api/releases	36 releases with correct GA dates, capabilities, previous release chain, product, and status
GET /api/releases/health?release=4.22	6 payload health reports
GET /api/component_readiness (4.21→4.22 with full params)	72 components, 38 columns
GET /api/component_readiness/regressions?release=4.22	4,545 regressions

All release data served from PostgreSQL with no BigQuery calls.

Ref: TRT-2734

@coderabbitai ignore

🤖 Generated with Claude Code

[openshift-merge-bot]

Pipeline controller notification
This repo is configured to use the pipeline controller. Second-stage tests will be triggered either automatically or after lgtm label is added, depending on the repository configuration. The pipeline controller will automatically detect which contexts are required and will utilize /test Prow commands to trigger the second stage.

For optional jobs, comment /test ? to see a list of all defined jobs. To trigger manually all jobs from second stage use /pipeline required command.

This repository is configured in: automatic mode

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: mstaeble
Once this PR has been reviewed and has the lgtm label, please assign deepsm007 for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-merge-bot]

Scheduling required tests:
/test e2e

[openshift-ci]

@mstaeble: all tests passed!

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

[sosiouxme]

this removes the cache. reading from a small postgres table is fast, but not nearly as fast as reading from redis, and this page gets called.... a lot. with React calling it several times per UI transition it may even be noticeable at a human timescale. consider whether we don't want caching here?

[mstaeble]

Good call raising this. I traced all the callers to understand the full impact.

getReleases() is called by 8 HTTP handlers:

• /api/releases (page load, ~15 calls/hour)
• /api/component_readiness (every CR request)
• /api/component_readiness/test_details
• /api/component_readiness/views
• 4 triage/regression endpoints

The old Redis cache (8h TTL, key "Releases~") was valuable because it avoided a BigQuery round-trip on every one of these requests. That saved both latency and BQ query cost.

With PostgreSQL, the query is ~7ms for ~20 rows. The CR endpoints themselves take seconds, so 7ms is noise. There's no per-query cost like BQ.

More importantly, these callers are transitional. The CR handlers use release data for two things: resolving relative time strings like "ga-30d" into absolute dates, and generating HATEOAS links with correct time parameters. As we move CR fully to PostgreSQL:

1. The CR test status queries will use pre-aggregated matviews per release (e.g., cr_base_agg_4.21), where the GA-based time window is baked into the matview at build time. No release metadata lookup needed at request time.
2. For any queries that still need release dates, the lookup can fold into the main query as a JOIN against release_definitions rather than a separate round-trip.

That leaves /api/releases as the only endpoint that needs a standalone query, at ~15 calls/hour. Adding a Redis cache layer for that adds complexity with no user-visible benefit. The HTTP round-trip overhead alone (~50-200ms) dwarfs the 7ms PG query.

If we see this become a bottleneck in practice, we can add caching for PQ later, but I don't think it's warranted now.