Make BigQuery optional for local development - #801
Conversation
📝 WalkthroughWalkthroughThe release payload controller no longer requires BigQuery credentials during validation and initializes BigQuery only when both credential values are present. A new test verifies Jira escalation controller construction succeeds with a nil BigQuery client. ChangesOptional BigQuery startup
Estimated code review effort: 2 (Simple) | ~10 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: JoelSpeed The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
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/cmd/release-payload-controller/cmd.go`:
- Around line 85-98: The Validate method incorrectly accesses the unavailable
flagutil.JiraOptions.Endpoint field. Track whether Jira is configured using a
supported Jira configuration check or stored state, then use that state to gate
the GoogleProjectID and GoogleServiceAccountCredentialFile validations while
preserving the existing Jira validation.
🪄 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: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: b8bce586-5853-4039-a74c-10028cf52646
📒 Files selected for processing (1)
pkg/cmd/release-payload-controller/cmd.go
0657e65 to
fee0591
Compare
fee0591 to
7e52046
Compare
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
pkg/cmd/release-payload-controller/cmd.go (1)
84-89: 🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick winRequire a usable BigQuery client whenever Jira is enabled.
Validatenow accepts configured Jira without checking BigQuery, whileRuntreats missing credentials andNewBigQueryClientfailures as non-fatal and passes a nil client to the Jira controller. This violates the stated contract and can silently start a degraded Jira escalation path. Require both credentials and fail startup on BigQuery initialization errors when Jira is configured; retain the optional path only when Jira is disabled.Also applies to: 147-163
🤖 Prompt for 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. In `@pkg/cmd/release-payload-controller/cmd.go` around lines 84 - 89, Update Options.Validate and the Jira-enabled startup path in Run to require BigQuery credentials and successfully initialize NewBigQueryClient whenever Jira is configured; return validation or initialization errors instead of continuing with a nil client. Preserve the optional BigQuery behavior only when Jira is disabled.
🤖 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.
Outside diff comments:
In `@pkg/cmd/release-payload-controller/cmd.go`:
- Around line 84-89: Update Options.Validate and the Jira-enabled startup path
in Run to require BigQuery credentials and successfully initialize
NewBigQueryClient whenever Jira is configured; return validation or
initialization errors instead of continuing with a nil client. Preserve the
optional BigQuery behavior only when Jira is disabled.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: 78e524fc-999a-4cd9-bb40-d2c168469c29
📒 Files selected for processing (2)
pkg/cmd/release-payload-controller/cmd.gopkg/cmd/release-payload-controller/jira_escalations_controller_test.go
|
@JoelSpeed: The following test failed, say
Full PR test history. Your PR dashboard. DetailsInstructions 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. |
|
I have the fix for the Also, CodeRabbit's latest finding seem legit as well. |
Do you mean #801 (review), this was what I tried to fix in my original patch, but I thought we had concluded that this wasn't possible in a non-hacky way without looking up the flag. Unless I'm missing something, there's no easy way to understand if the jira controller is, or is not enabled |
2 participants
The bigquery requirement was added recently and makes local development of the majority of release payload controller difficult (since I'd have to set up a bigquery).
As far as I can tell the bigquery stuff is only used in one of the controllers. This PR makes the bigquery client optional (to match the jira client) for local dev.
Summary by CodeRabbit