TRT-2803: Consolidate release loader PG and BQ queries into bulk operations

[mstaeble]

Summary

• Restructure the release loader Load() into a staged pipeline: fetch all stream tags, update phase changes and find new tags via temp table, fetch tag details, apply bulk labels, resolve all PRs, and bulk write
• Replace per-tag PG queries (existence checks, phase updates, individual writes) with bulk operations using the CopyToTempTable helper from Add pgx helpers: PgxSession interface and CopyToTempTable generic #3759
• Parallelize HTTP fetches to the release controller with a 10-worker pool using sync.WaitGroup.Go
• Consolidate per-tag BQ label queries into a single GatherLabelsFromBQ call across all new tags
• Consolidate per-tag PR resolution into a single temp table + COPY + upsert operation
• Wrap bulk writes in a transaction for atomicity

Staging results

Tested against a staging DB clone (23h behind prod).

Single release (4.22, 10 new tags):

	Old code	New code	Speedup
Total time	43.0s	9.4s	4.6x
PG tag checks	~111 individual SELECTs	1 COPY + 2 queries	~111 → 3
BQ label queries	9 separate calls	1 call (238 build IDs)	9 → 1
PR resolution	11 separate OR-chain queries	1 COPY + upsert + SELECT	11 → 3
Data diff	none	none	-

Full all-releases catch-up (128 new tags):

	Old code	New code	Speedup
Total time	5m37s	2m9s	2.6x
Tags	128	128	identical
Job runs	1,076	1,076	identical
PRs (join table)	3,527	3,527	identical
Repositories	625	625	identical
BQ queries	~128 separate	1 (1,076 build IDs)	128 → 1
PG tag checks	~1,375 SELECTs	1 COPY + 2 queries	~1,375 → 3
Data diff	none	none	-

Steady-state (no new tags): 508ms (just the temp table filter).

Test plan

• make lint passes
• make test passes
• make e2e passes
• Staging DB comparison: new code produces identical results to old code across all releases

🤖 Generated with Claude Code

Co-Authored-By: Claude Opus 4.6 noreply@anthropic.com

Summary by CodeRabbit

• Improvements
  • Release synchronization now processes tags, pull requests, repositories, and job runs in bulk for improved performance on large release sets.
  • Release labels and job-run details are applied consistently during synchronization.
  • Release data processing now handles multiple architectures more reliably.
• Bug Fixes
  • Corrected job-run status handling and improved validation of blocking and informing job runs.

[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 xueqzhan 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

[mstaeble]

@coderabbiai review

[mstaeble]

@coderabbitai full review

[coderabbitai]

✅ Action performed

Full review finished.

[coderabbitai]

Walkthrough

Release synchronization now uses concurrent tag loading, batched label and pull-request resolution, and pgx-based transactional persistence. Job-run construction is separated from bulk label application, with updated unit and functional tests.

Changes

Release synchronization

Layer / File(s)	Summary
Concurrent loading and bulk persistence pkg/dataloader/releaseloader/releasesync.go	Release tags are loaded concurrently, filtered through temporary SQL tables, resolved with bulk pull-request queries, and persisted with pgx transaction helpers.
Job-run construction and bulk labels pkg/dataloader/releaseloader/releasesync.go	Job runs are built separately from label lookup; upgrade metadata is applied and labels are fetched in bulk.
Test fixtures and flow validation pkg/dataloader/releaseloader/releasesync_functional_test.go, pkg/dataloader/releaseloader/releasesync_test.go	Tests use capitalized job-run states, validate job-run construction, and exercise label application through ReleaseTag.

Estimated code review effort: 4 (Complex) | ~60 minutes

Sequence Diagram(s)

sequenceDiagram
  participant ReleaseLoader
  participant ReleaseStreams
  participant BigQuery
  participant PostgreSQL
  ReleaseLoader->>ReleaseStreams: fetch streams and tags concurrently
  ReleaseLoader->>PostgreSQL: identify new phase-relevant tags
  ReleaseLoader->>BigQuery: fetch labels for built job runs
  ReleaseLoader->>PostgreSQL: resolve pull requests and persist associations

Loading

Suggested reviewers: sosiouxme, kenjpais, smg247

🚥 Pre-merge checks | ✅ 19 | ❌ 2

❌ Failed checks (2 warnings)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 28.57% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.
Ipv6 And Disconnected Network Test Compatibility	⚠️ Warning	New functional test fetches a public release-controller URL and BigQuery, so it assumes external connectivity and breaks in disconnected CI.	Mark the test [Skipped:Disconnected] or gate it behind an opt-in env var; avoid public endpoints and require internal/cluster-local services only.

✅ Passed checks (19 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Go Error Handling	✅ Passed	No new ignored errors, panics, or nil dereferences; loader failures are wrapped at call boundaries and temp-table cleanup is always non-nil.
Sql Injection Prevention	✅ Passed	PASS: New queries are static; data is loaded via CopyFrom/temp tables, and temp-table names are fixed/validated, so no user input is concatenated into SQL text.
Excessive Css In React Should Use Styles	✅ Passed	No React components or inline styles were changed; the PR only touches Go release-loader files, so this CSS/style check is not applicable.
Test Coverage For New Features	✅ Passed	PASS: buildJobRuns and extractBuildIDFromURL have unit tests, applyBulkLabels has a functional test, and releaseDetailsToDB remains covered by TestReleaseTagForcedFlag.
Single Responsibility And Clear Naming	✅ Passed	The releaseloader package stays cohesive, and the new methods are descriptively named and split into clear stages with no clearly overbroad helpers.
Feature Documentation	✅ Passed	No docs/features files changed; the only relevant doc already covers release-loader label ingestion, and this PR is an internal bulk refactor.
Stable And Deterministic Test Names	✅ Passed	Changed tests use only static literal names; no Ginkgo-style titles or dynamic values appear in test names.
Test Structure And Quality	✅ Passed	PASS: No Ginkgo/cluster patterns were added; the tests are standard Go tests, skip safely on missing env, and the functional test sets an HTTP timeout.
Microshift Test Compatibility	✅ Passed	No new Ginkgo e2e tests were added; the changed functional test only uses BigQuery and the release controller, with no MicroShift-unsupported OpenShift APIs.
Single Node Openshift (Sno) Test Compatibility	✅ Passed	No new Ginkgo e2e tests were added in the touched files, and no SNO-sensitive multi-node assumptions or guards were present.
Topology-Aware Scheduling Compatibility	✅ Passed	This PR only changes the release dataloader and tests; no deployment manifests, operator code, or scheduling/controller logic was modified.
Ote Binary Stdout Contract	✅ Passed	No process-level stdout writes found: touched files only define normal tests and loader methods; no main/TestMain/init/RunSpecs or fmt.Print/klog stdout calls.
No-Weak-Crypto	✅ Passed	Changed files only add HTTP/SQL/bulk-loading logic; imports and new functions contain no weak crypto or secret comparisons.
Container-Privileges	✅ Passed	Only Go source/tests changed; no container/K8s manifests or privileged settings appear in the diff.
No-Sensitive-Data-In-Logs	✅ Passed	New logs only emit release tags, public CI URLs/build IDs, counts, and errors; no passwords, tokens, PII, or customer data found.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately summarizes the main change: consolidating release loader database and query work into bulk operations.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@pkg/dataloader/releaseloader/releasesync.go`:
- Around line 448-462: Update the release-tag insertion flow around the INSERT
into release_tags to prevent duplicate release_tag values from being written
when tmp_release_tags_insert contains repeated tags. Prefer an upsert or input
deduplication keyed by release_tag, while preserving the existing field
population and returning the database error from this operation.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository YAML (base), Central YAML (inherited)

Review profile: CHILL

Plan: Enterprise

Run ID: 94ede468-597c-4e65-a3fd-1ac097721d49

📥 Commits

Reviewing files that changed from the base of the PR and between 8876d58 and dfe6b3b.

📒 Files selected for processing (3)

• pkg/dataloader/releaseloader/releasesync.go
• pkg/dataloader/releaseloader/releasesync_functional_test.go
• pkg/dataloader/releaseloader/releasesync_test.go

[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.

[openshift-ci-robot]

@mstaeble: This pull request references TRT-2801 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "5.0.0" version, but no target version was set.

Details

In response to this:

Summary

• Restructure the release loader Load() into a staged pipeline: fetch all stream tags, update phase changes and find new tags via temp table, fetch tag details, apply bulk labels, resolve all PRs, and bulk write
• Replace per-tag PG queries (existence checks, phase updates, individual writes) with bulk operations using the CopyToTempTable helper from Add pgx helpers: PgxSession interface and CopyToTempTable generic #3759
• Parallelize HTTP fetches to the release controller with a 10-worker pool using sync.WaitGroup.Go
• Consolidate per-tag BQ label queries into a single GatherLabelsFromBQ call across all new tags
• Consolidate per-tag PR resolution into a single temp table + COPY + upsert operation
• Wrap bulk writes in a transaction for atomicity

Staging results

Tested against a staging DB clone (23h behind prod).

Single release (4.22, 10 new tags):

	Old code	New code	Speedup
Total time	43.0s	9.4s	4.6x
PG tag checks	~111 individual SELECTs	1 COPY + 2 queries	~111 → 3
BQ label queries	9 separate calls	1 call (238 build IDs)	9 → 1
PR resolution	11 separate OR-chain queries	1 COPY + upsert + SELECT	11 → 3
Data diff	none	none	-

Full all-releases catch-up (128 new tags):

	Old code	New code	Speedup
Total time	5m37s	2m9s	2.6x
Tags	128	128	identical
Job runs	1,076	1,076	identical
PRs (join table)	3,527	3,527	identical
Repositories	625	625	identical
BQ queries	~128 separate	1 (1,076 build IDs)	128 → 1
PG tag checks	~1,375 SELECTs	1 COPY + 2 queries	~1,375 → 3
Data diff	none	none	-

Steady-state (no new tags): 508ms (just the temp table filter).

Test plan

• make lint passes
• make test passes
• make e2e passes
• Staging DB comparison: new code produces identical results to old code across all releases

🤖 Generated with Claude Code

Co-Authored-By: Claude Opus 4.6 noreply@anthropic.com

Summary by CodeRabbit

• Improvements
• Release synchronization now processes tags, pull requests, repositories, and job runs in bulk for improved performance on large release sets.
• Release labels and job-run details are applied consistently during synchronization.
• Release data processing now handles multiple architectures more reliably.
• Bug Fixes
• Corrected job-run status handling and improved validation of blocking and informing job runs.

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 openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@mstaeble: This pull request references TRT-2802 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "5.0.0" version, but no target version was set.

Details

In response to this:

Summary

• Restructure the release loader Load() into a staged pipeline: fetch all stream tags, update phase changes and find new tags via temp table, fetch tag details, apply bulk labels, resolve all PRs, and bulk write
• Replace per-tag PG queries (existence checks, phase updates, individual writes) with bulk operations using the CopyToTempTable helper from Add pgx helpers: PgxSession interface and CopyToTempTable generic #3759
• Parallelize HTTP fetches to the release controller with a 10-worker pool using sync.WaitGroup.Go
• Consolidate per-tag BQ label queries into a single GatherLabelsFromBQ call across all new tags
• Consolidate per-tag PR resolution into a single temp table + COPY + upsert operation
• Wrap bulk writes in a transaction for atomicity

Staging results

Tested against a staging DB clone (23h behind prod).

Single release (4.22, 10 new tags):

	Old code	New code	Speedup
Total time	43.0s	9.4s	4.6x
PG tag checks	~111 individual SELECTs	1 COPY + 2 queries	~111 → 3
BQ label queries	9 separate calls	1 call (238 build IDs)	9 → 1
PR resolution	11 separate OR-chain queries	1 COPY + upsert + SELECT	11 → 3
Data diff	none	none	-

Full all-releases catch-up (128 new tags):

	Old code	New code	Speedup
Total time	5m37s	2m9s	2.6x
Tags	128	128	identical
Job runs	1,076	1,076	identical
PRs (join table)	3,527	3,527	identical
Repositories	625	625	identical
BQ queries	~128 separate	1 (1,076 build IDs)	128 → 1
PG tag checks	~1,375 SELECTs	1 COPY + 2 queries	~1,375 → 3
Data diff	none	none	-

Steady-state (no new tags): 508ms (just the temp table filter).

Test plan

• make lint passes
• make test passes
• make e2e passes
• Staging DB comparison: new code produces identical results to old code across all releases

🤖 Generated with Claude Code

Co-Authored-By: Claude Opus 4.6 noreply@anthropic.com

Summary by CodeRabbit

• Improvements
• Release synchronization now processes tags, pull requests, repositories, and job runs in bulk for improved performance on large release sets.
• Release labels and job-run details are applied consistently during synchronization.
• Release data processing now handles multiple architectures more reliably.
• Bug Fixes
• Corrected job-run status handling and improved validation of blocking and informing job runs.

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 openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@mstaeble: This pull request references TRT-2803 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "5.0.0" version, but no target version was set.

Details

In response to this:

Summary

• Restructure the release loader Load() into a staged pipeline: fetch all stream tags, update phase changes and find new tags via temp table, fetch tag details, apply bulk labels, resolve all PRs, and bulk write
• Replace per-tag PG queries (existence checks, phase updates, individual writes) with bulk operations using the CopyToTempTable helper from Add pgx helpers: PgxSession interface and CopyToTempTable generic #3759
• Parallelize HTTP fetches to the release controller with a 10-worker pool using sync.WaitGroup.Go
• Consolidate per-tag BQ label queries into a single GatherLabelsFromBQ call across all new tags
• Consolidate per-tag PR resolution into a single temp table + COPY + upsert operation
• Wrap bulk writes in a transaction for atomicity

Staging results

Tested against a staging DB clone (23h behind prod).

Single release (4.22, 10 new tags):

	Old code	New code	Speedup
Total time	43.0s	9.4s	4.6x
PG tag checks	~111 individual SELECTs	1 COPY + 2 queries	~111 → 3
BQ label queries	9 separate calls	1 call (238 build IDs)	9 → 1
PR resolution	11 separate OR-chain queries	1 COPY + upsert + SELECT	11 → 3
Data diff	none	none	-

Full all-releases catch-up (128 new tags):

	Old code	New code	Speedup
Total time	5m37s	2m9s	2.6x
Tags	128	128	identical
Job runs	1,076	1,076	identical
PRs (join table)	3,527	3,527	identical
Repositories	625	625	identical
BQ queries	~128 separate	1 (1,076 build IDs)	128 → 1
PG tag checks	~1,375 SELECTs	1 COPY + 2 queries	~1,375 → 3
Data diff	none	none	-

Steady-state (no new tags): 508ms (just the temp table filter).

Test plan

• make lint passes
• make test passes
• make e2e passes
• Staging DB comparison: new code produces identical results to old code across all releases

🤖 Generated with Claude Code

Co-Authored-By: Claude Opus 4.6 noreply@anthropic.com

Summary by CodeRabbit

• Improvements
• Release synchronization now processes tags, pull requests, repositories, and job runs in bulk for improved performance on large release sets.
• Release labels and job-run details are applied consistently during synchronization.
• Release data processing now handles multiple architectures more reliably.
• Bug Fixes
• Corrected job-run status handling and improved validation of blocking and informing job runs.

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 openshift-eng/jira-lifecycle-plugin repository.