fix: guard against nil RootKeySecretRef in TUF init job by miyunari · Pull Request #1733 · securesign/secure-sign-operator

miyunari · 2026-04-12T18:47:35Z

Summary

During an upgrade from an older operator version, RootKeySecretRef may be nil if the field wasn't present in the original CRD. EnsureTufInitJob dereferences it without a nil check, causing a panic.
Added a nil guard that returns a clear error (rootKeySecretRef is not set) instead of panicking.
Added unit tests for both the nil case (safe error state) and the normal case (correct --export-keys argument).

Supersedes #1732
Related: SECURESIGN-4125

Test plan

TestEnsureTufInitJob_NilRootKeySecretRef — verifies nil RootKeySecretRef produces a clean error, no panic
TestEnsureTufInitJob_WithRootKeySecretRef — verifies normal operation and correct job args
All existing TUF controller and action tests pass

🤖 Generated with Claude Code

During an upgrade, the RootKeySecretRef field may be nil if the resource was created by an older operator version. This causes a nil pointer dereference panic in EnsureTufInitJob. Return a clear error instead. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

qodo-code-review · 2026-04-12T18:47:49Z

PR Type

Bug fix, Tests

Description

Guard against nil RootKeySecretRef in TUF init job to prevent panic during upgrades
Return clear error message when RootKeySecretRef is not set instead of dereferencing nil
Add comprehensive unit tests for nil and valid RootKeySecretRef scenarios

File Walkthrough

Relevant files

Bug fix

tuf_init_job.go `Add nil guard for RootKeySecretRef field` internal/controller/tuf/utils/tuf_init_job.go Added nil check for `instance.Spec.RootKeySecretRef` at the start of `EnsureTufInitJob` function Returns formatted error message "rootKeySecretRef is not set" when field is nil Prevents nil pointer dereference panic that occurred during operator upgrades	+4/-0

Tests

tuf_init_job_test.go `Add unit tests for TUF init job nil handling` internal/controller/tuf/utils/tuf_init_job_test.go New test file with comprehensive unit test coverage for `EnsureTufInitJob` function `TestEnsureTufInitJob_NilRootKeySecretRef` verifies nil field produces expected error without panic `TestEnsureTufInitJob_WithRootKeySecretRef` validates normal operation with valid `RootKeySecretRef` and correct job arguments Includes helper function `contains` for argument validation	+107/-0

qodo-code-review · 2026-04-12T18:47:51Z

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (0) 📎 Requirement gaps (0) 🖥 UI issues (0) 🎨 UX Issues (0)

🐞\ ≡ Correctness (1) ☼ Reliability (1)

1. Non-terminal missing rootKey 🐞 ☼

Description

When RootKeySecretRef is nil, EnsureTufInitJob returns a plain error, and initJobAction
wraps/returns it as a non-terminal error so the controller won’t set ReadyCondition=False and will
keep retrying job creation. This undermines the goal of a “clear error state” during upgrades
because the failure may only appear in logs/reconcile errors, not in status conditions.

Code

internal/controller/tuf/utils/tuf_init_job.go[R26-28]
+		if instance.Spec.RootKeySecretRef == nil {
+			return fmt.Errorf("rootKeySecretRef is not set")
+		}

Evidence
EnsureTufInitJob returns a plain error for nil RootKeySecretRef; initJobAction propagates
CreateOrUpdate errors via i.Error(ctx, fmt.Errorf(...)) without reconcile.TerminalError or explicit
conditions, and BaseAction.Error only updates status conditions for terminal errors or when
conditions are provided.
internal/controller/tuf/utils/tuf_init_job.go[24-32]
internal/controller/tuf/actions/tuf_init_job.go[96-122]
internal/action/base_action.go[73-104]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`EnsureTufInitJob` returns a non-terminal error when `spec.rootKeySecretRef` is missing. The `tuf-init` action propagates this as a non-terminal reconcile error, so the operator may keep retrying without surfacing a clear `Ready` failure condition.

### Issue Context
This occurs on upgrade paths where older stored CRs can have `spec.rootKeySecretRef` absent.

### Fix Focus Areas
- internal/controller/tuf/actions/tuf_init_job.go[96-122]
- internal/controller/tuf/utils/tuf_init_job.go[24-32]

### Implementation notes
- Add a precondition check in `initJobAction.ensureInitJob`:
 - if `instance.Spec.RootKeySecretRef == nil` (and ideally also `Name == ""`), return `i.Error(ctx, reconcile.TerminalError(fmt.Errorf("...")), instance)` (or pass an explicit failure condition).
- Optionally keep the util-level guard as defense-in-depth, but ensure the action surfaces the condition clearly.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. Empty rootKey secret name 🐞 ≡

Description

The new guard only checks RootKeySecretRef for nil, but does not validate RootKeySecretRef.Name; if
the pointer exists with an empty Name, the init job command is built with an empty --export-keys
value. This can lead to a failing init job (and the codebase already treats empty Name as invalid in
the migration path).

Code

internal/controller/tuf/utils/tuf_init_job.go[R26-31]

+		if instance.Spec.RootKeySecretRef == nil {
+			return fmt.Errorf("rootKeySecretRef is not set")
+		}
+
		// prepare args
		args := []string{"--operator", constants.OperatorName, "--export-keys", instance.Spec.RootKeySecretRef.Name}

Evidence

EnsureTufInitJob proceeds to build args using instance.Spec.RootKeySecretRef.Name after only a nil
check. In contrast, migrationJobAction explicitly requires both non-nil and non-empty Name,
indicating empty Name is an invalid state that should be rejected here too.

internal/controller/tuf/utils/tuf_init_job.go[24-32]
internal/controller/tuf/actions/migration_job.go[54-66]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`EnsureTufInitJob` guards only against `RootKeySecretRef == nil` but still accepts `RootKeySecretRef.Name == ""`, producing an invalid `--export-keys` argument.

### Issue Context
Other controller paths (migration job) already validate both non-nil and non-empty `Name`, so this is an inconsistency and can still break upgrades or malformed stored CRs.

### Fix Focus Areas
- internal/controller/tuf/utils/tuf_init_job.go[24-32]
- internal/controller/tuf/utils/tuf_init_job_test.go[43-107]

### Implementation notes
- Change the guard to:
 - `if instance.Spec.RootKeySecretRef == nil || instance.Spec.RootKeySecretRef.Name == "" { ... }`
- Add a unit test covering `RootKeySecretRef: &LocalObjectReference{Name: ""}` expecting an error.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

ⓘ The new review experience is currently in Beta. Learn more

qodo-code-review · 2026-04-12T18:51:05Z

+		if instance.Spec.RootKeySecretRef == nil {
+			return fmt.Errorf("rootKeySecretRef is not set")
+		}


1. Non-terminal missing rootkey 🐞 Bug ☼ Reliability

When RootKeySecretRef is nil, EnsureTufInitJob returns a plain error, and initJobAction wraps/returns it as a non-terminal error so the controller won’t set ReadyCondition=False and will keep retrying job creation. This undermines the goal of a “clear error state” during upgrades because the failure may only appear in logs/reconcile errors, not in status conditions.

Agent Prompt

### Issue description `EnsureTufInitJob` returns a non-terminal error when `spec.rootKeySecretRef` is missing. The `tuf-init` action propagates this as a non-terminal reconcile error, so the operator may keep retrying without surfacing a clear `Ready` failure condition. ### Issue Context This occurs on upgrade paths where older stored CRs can have `spec.rootKeySecretRef` absent. ### Fix Focus Areas - internal/controller/tuf/actions/tuf_init_job.go[96-122] - internal/controller/tuf/utils/tuf_init_job.go[24-32] ### Implementation notes - Add a precondition check in `initJobAction.ensureInitJob`: - if `instance.Spec.RootKeySecretRef == nil` (and ideally also `Name == ""`), return `i.Error(ctx, reconcile.TerminalError(fmt.Errorf("...")), instance)` (or pass an explicit failure condition). - Optionally keep the util-level guard as defense-in-depth, but ensure the action surfaces the condition clearly.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

qodo-code-review · 2026-04-12T18:51:07Z

Code Review by Qodo

🐞 Bugs (4) 📘 Rule violations (0) 📎 Requirement gaps (0) 🖥 UI issues (0) 🎨 UX Issues (0)

🐞\ ≡ Correctness (1) ☼ Reliability (1) ⚙ Maintainability (1) ◔ Observability (1) ⭐ New (2)

1. Non-terminal missing rootKey 🐞 ☼

Description

When RootKeySecretRef is nil, EnsureTufInitJob returns a plain error, and initJobAction
wraps/returns it as a non-terminal error so the controller won’t set ReadyCondition=False and will
keep retrying job creation. This undermines the goal of a “clear error state” during upgrades
because the failure may only appear in logs/reconcile errors, not in status conditions.

Code

internal/controller/tuf/utils/tuf_init_job.go[R26-28]
+		if instance.Spec.RootKeySecretRef == nil {
+			return fmt.Errorf("rootKeySecretRef is not set")
+		}

Evidence
EnsureTufInitJob returns a plain error for nil RootKeySecretRef; initJobAction propagates
CreateOrUpdate errors via i.Error(ctx, fmt.Errorf(...)) without reconcile.TerminalError or explicit
conditions, and BaseAction.Error only updates status conditions for terminal errors or when
conditions are provided.
internal/controller/tuf/utils/tuf_init_job.go[24-32]
internal/controller/tuf/actions/tuf_init_job.go[96-122]
internal/action/base_action.go[73-104]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`EnsureTufInitJob` returns a non-terminal error when `spec.rootKeySecretRef` is missing. The `tuf-init` action propagates this as a non-terminal reconcile error, so the operator may keep retrying without surfacing a clear `Ready` failure condition.
### Issue Context
This occurs on upgrade paths where older stored CRs can have `spec.rootKeySecretRef` absent.
### Fix Focus Areas
- internal/controller/tuf/actions/tuf_init_job.go[96-122]
- internal/controller/tuf/utils/tuf_init_job.go[24-32]
### Implementation notes
- Add a precondition check in `initJobAction.ensureInitJob`:
- if `instance.Spec.RootKeySecretRef == nil` (and ideally also `Name == ""`), return `i.Error(ctx, reconcile.TerminalError(fmt.Errorf("...")), instance)` (or pass an explicit failure condition).
- Optionally keep the util-level guard as defense-in-depth, but ensure the action surfaces the condition clearly.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. Error not surfaced in status 🐞 ◔ ⭐

Description

When spec.rootKeySecretRef is nil, EnsureTufInitJob now returns an error, but the init-job
action path wraps/returns it without setting any status conditions, so the Tuf CR won’t show why
reconciliation is stuck failing. This can cause repeated reconcile failures (log noise/retries) with
poor user visibility during upgrades/misconfiguration.

Code

internal/controller/tuf/utils/tuf_init_job.go[R26-28]
+		if instance.Spec.RootKeySecretRef == nil {
+			return fmt.Errorf("rootKeySecretRef is not set")
+		}

Evidence
EnsureTufInitJob returns a plain error on nil RootKeySecretRef, and the controller’s error
handling only writes conditions for terminal errors or when explicit conditions are
provided—initJobAction.ensureInitJob does neither when CreateOrUpdate fails, so the error won’t be
reflected in .status.conditions.
internal/controller/tuf/utils/tuf_init_job.go[24-33]
internal/controller/tuf/actions/tuf_init_job.go[96-122]
internal/action/base_action.go[73-104]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`EnsureTufInitJob` now returns an error when `spec.rootKeySecretRef` is nil, but this user-actionable validation failure is not surfaced in the Tuf CR status conditions. As a result, reconciliation can repeatedly fail without an obvious reason in `kubectl get/describe` output.

## Issue Context
`BaseAction.Error` only updates status when the error is terminal and/or when explicit conditions are passed in. `initJobAction.ensureInitJob` currently calls `i.Error(...)` without terminal wrapping and without passing conditions, so the failure reason never reaches `.status.conditions`.

## Fix Focus Areas
- internal/controller/tuf/actions/tuf_init_job.go[96-122]
- internal/action/base_action.go[73-104]
- internal/controller/tuf/utils/tuf_init_job.go[24-33]

## Suggested implementation direction
- Detect/propagate the nil-rootKey error as a terminal/config error OR pass an explicit condition into `i.Error(...)`.
- Set an appropriate condition (e.g., `RepositoryCondition=False` and/or `ReadyCondition=False`) with a clear message like `spec.rootKeySecretRef is required` so users can diagnose via CR status.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

3. Empty rootKey secret name 🐞 ≡

Description

The new guard only checks RootKeySecretRef for nil, but does not validate RootKeySecretRef.Name; if
the pointer exists with an empty Name, the init job command is built with an empty --export-keys
value. This can lead to a failing init job (and the codebase already treats empty Name as invalid in
the migration path).

Code

internal/controller/tuf/utils/tuf_init_job.go[R26-31]

+		if instance.Spec.RootKeySecretRef == nil {
+			return fmt.Errorf("rootKeySecretRef is not set")
+		}
+
  	// prepare args
  	args := []string{"--operator", constants.OperatorName, "--export-keys", instance.Spec.RootKeySecretRef.Name}

Evidence

EnsureTufInitJob proceeds to build args using instance.Spec.RootKeySecretRef.Name after only a nil
check. In contrast, migrationJobAction explicitly requires both non-nil and non-empty Name,
indicating empty Name is an invalid state that should be rejected here too.

internal/controller/tuf/utils/tuf_init_job.go[24-32]
internal/controller/tuf/actions/migration_job.go[54-66]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`EnsureTufInitJob` guards only against `RootKeySecretRef == nil` but still accepts `RootKeySecretRef.Name == ""`, producing an invalid `--export-keys` argument.
### Issue Context
Other controller paths (migration job) already validate both non-nil and non-empty `Name`, so this is an inconsistency and can still break upgrades or malformed stored CRs.
### Fix Focus Areas
- internal/controller/tuf/utils/tuf_init_job.go[24-32]
- internal/controller/tuf/utils/tuf_init_job_test.go[43-107]
### Implementation notes
- Change the guard to:
- `if instance.Spec.RootKeySecretRef == nil || instance.Spec.RootKeySecretRef.Name == "" { ... }`
- Add a unit test covering `RootKeySecretRef: &LocalObjectReference{Name: ""}` expecting an error.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

4. Redundant contains() in test 🐞 ⚙ ⭐

Description

The new unit test reimplements substring search with a custom contains() helper instead of using
strings.Contains, increasing maintenance surface. This is especially unnecessary since the job
args are intentionally a single joined shell string (strings.Join(args, " ")).

Code

internal/controller/tuf/utils/tuf_init_job_test.go[R89-107]

+	for _, arg := range container.Args {
+		if len(arg) > 0 && contains(arg, "--export-keys tuf-root-keys") {
+			found = true
+			break
+		}
+	}
+	if !found {
+		t.Errorf("expected --export-keys tuf-root-keys in args, got: %v", container.Args)
+	}
+}
+
+func contains(s, substr string) bool {
+	for i := 0; i <= len(s)-len(substr); i++ {
+		if s[i:i+len(substr)] == substr {
+			return true
+		}
+	}
+	return false
+}

Evidence
The production code builds container.Args as a single bash command string and the test only needs
a substring check; the standard library already provides strings.Contains for this.
internal/controller/tuf/utils/tuf_init_job.go[99-104]
internal/controller/tuf/utils/tuf_init_job_test.go[86-107]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The unit test adds a custom `contains()` helper that duplicates `strings.Contains`, increasing code to maintain for no functional benefit.

## Issue Context
`EnsureTufInitJob` sets `container.Args` to a single shell command string, so checking `strings.Contains(container.Args[0], "--export-keys tuf-root-keys")` is sufficient and clearer.

## Fix Focus Areas
- internal/controller/tuf/utils/tuf_init_job_test.go[86-107]
- internal/controller/tuf/utils/tuf_init_job.go[99-104]

## Suggested implementation direction
- Import `strings` in the test file.
- Replace the loop + custom `contains()` with `strings.Contains(container.Args[0], "--export-keys tuf-root-keys")` (or similar).
- Delete the custom helper.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

ⓘ The new review experience is currently in Beta. Learn more

Add TestMigrateJob_NilRootKeySecretRef to verify the migration action handles the case where TUF signing keys are stored externally and RootKeySecretRef is nil. Asserts that: - a terminal error is returned with a clear message - the deployment is not touched (non-destructive) - no migration job is created Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

qodo-code-review · 2026-04-12T19:03:19Z

CI Feedback 🧐

A test triggered by this PR failed. Here is an AI-generated analysis of the failure:

Action: golangci
Failed stage: golangci-lint [❌]
Failed test name: ""
Failure summary: The action failed during `golangci-lint run` because `gofmt` detected an unformatted Go source file: - `internal/controller/tuf/actions/migration_job_test.go:139:1`: "File is not properly formatted (gofmt)" After filtering, `golangci-lint` reported 1 remaining issue and exited with `issues found`, causing the workflow step to fail.
Relevant error logs: 1: ##[group]Runner Image Provisioner 2: Hosted Compute Agent ... 208: install-mode: binary 209: install-only: false 210: github-token: *** 211: verify: true 212: only-new-issues: false 213: skip-cache: false 214: skip-save-cache: false 215: cache-invalidation-interval: 7 216: problem-matchers: false 217: ##[endgroup] 218: ##[group]Restore cache 219: Checking for go.mod: go.mod 220: (node:2355) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead. 221: (Use `node --trace-deprecation ...` to show where the warning was created) 222: Cache hit for: golangci-lint.cache-Linux-2936-93e8a17b4f356a599dc80e9a78e422abd3301a4d 223: (node:2355) [DEP0169] DeprecationWarning: `url.parse()` behavior is not standardized and prone to errors that have security implications. Use the WHATWG URL API instead. CVEs are not issued for `url.parse()` vulnerabilities. 224: Received 1287418 of 1287418 (100.0%), 2.1 MBs/sec ... 227: Cache restored successfully 228: Restored cache for golangci-lint from key 'golangci-lint.cache-Linux-2936-93e8a17b4f356a599dc80e9a78e422abd3301a4d' in 1329ms 229: ##[endgroup] 230: ##[group]Install 231: Finding needed golangci-lint version... 232: Installation mode: binary 233: Installing golangci-lint binary v2.8.0... 234: Downloading binary https://github.com/golangci/golangci-lint/releases/download/v2.8.0/golangci-lint-2.8.0-linux-amd64.tar.gz ... 235: [command]/usr/bin/tar xz --overwrite --warning=no-unknown-keyword --overwrite -C /home/runner -f /home/runner/work/_temp/91b0f9ff-821a-48ae-b8ef-6cec68ddd497 236: Installed golangci-lint into /home/runner/golangci-lint-2.8.0-linux-amd64/golangci-lint in 817ms 237: ##[endgroup] 238: ##[group]run golangci-lint 239: Running [/home/runner/golangci-lint-2.8.0-linux-amd64/golangci-lint config path] in [/home/runner/work/secure-sign-operator/secure-sign-operator] ... 240: Running [/home/runner/golangci-lint-2.8.0-linux-amd64/golangci-lint config verify] in [/home/runner/work/secure-sign-operator/secure-sign-operator] ... 241: Running [/home/runner/golangci-lint-2.8.0-linux-amd64/golangci-lint run --verbose --timeout=15m] in [/home/runner/work/secure-sign-operator/secure-sign-operator] ... 242: ##[error]internal/controller/tuf/actions/migration_job_test.go:139:1: File is not properly formatted (gofmt) 243: RootKeySecretRef: nil, ... 257: level=info msg="[linters_context/goanalysis] analyzers took 377.938357ms with top 10 stages: buildir: 67.310173ms, goimports: 66.127949ms, goconst: 56.961406ms, unparam: 38.183797ms, S1038: 13.242227ms, QF1004: 10.42947ms, buildssa: 9.450465ms, gofmt: 8.572533ms, misspell: 7.447939ms, unconvert: 5.284014ms" 258: level=info msg="[runner/exclusion_paths] Skipped 0 issues by pattern \"third_party$\"" 259: level=info msg="[runner/exclusion_paths] Skipped 0 issues by pattern \"builtin$\"" 260: level=info msg="[runner/exclusion_paths] Skipped 0 issues by pattern \"examples$\"" 261: level=info msg="[runner/exclusion_rules] Skipped 1 issues by rules: [Text: \"SA1019: manager.GetEventRecorderFor is deprecated\", Linters: \"staticcheck\"]" 262: level=info msg="[runner/exclusion_rules] Skipped 0 issues by rules: [Path: \"third_party$\", Linters: \"gofmt, goimports\"]" 263: level=info msg="[runner/exclusion_rules] Skipped 0 issues by rules: [Path: \"builtin$\", Linters: \"gofmt, goimports\"]" 264: level=info msg="[runner/exclusion_rules] Skipped 0 issues by rules: [Path: \"examples$\", Linters: \"gofmt, goimports\"]" 265: level=info msg="[runner] Issues before processing: 19, after processing: 1" 266: level=info msg="[runner] Processors filtering stat (in/out): cgo: 19/19, path_relativity: 19/19, nolint_filter: 17/2, fixer: 2/2, max_per_file_from_linter: 1/1, source_code: 1/1, severity-rules: 1/1, generated_file_filter: 19/18, exclusion_rules: 18/17, diff: 2/2, uniq_by_line: 2/1, sort_results: 1/1, max_same_issues: 1/1, path_absoluter: 19/19, filename_unadjuster: 19/19, invalid_issue: 19/19, max_from_linter: 1/1, path_shortener: 1/1, path_prettifier: 1/1, exclusion_paths: 19/19" 267: level=info msg="[runner] processing took 8.528226ms with stages: nolint_filter: 7.738076ms, generated_file_filter: 285.691µs, exclusion_paths: 246.522µs, exclusion_rules: 153.722µs, source_code: 42.995µs, path_relativity: 37.255µs, filename_unadjuster: 6.36µs, cgo: 2.593µs, uniq_by_line: 2.543µs, sort_results: 2.293µs, max_same_issues: 1.993µs, invalid_issue: 1.993µs, path_absoluter: 1.712µs, max_per_file_from_linter: 1.132µs, path_shortener: 1.041µs, max_from_linter: 862ns, fixer: 521ns, path_prettifier: 392ns, diff: 380ns, severity-rules: 150ns" 268: level=info msg="[runner] linters took 915.103612ms with stages: goanalysis_metalinter: 906.387423ms" 269: level=info msg="File cache stats: 1 entries of total size 11.8KiB" 270: level=info msg="Memory: 719 samples, avg is 38.3MB, max is 643.8MB" 271: level=info msg="Execution took 1m11.705183847s" 272: ##[error]issues found 273: Ran golangci-lint in 71836ms

bouskaJ · 2026-04-13T05:44:22Z

 func EnsureTufInitJob(instance *rhtasv1alpha1.Tuf, sa string, labels map[string]string, oidcIssuers []string) func(*batchv1.Job) error {
 	return func(job *batchv1.Job) error {
+		if instance.Spec.RootKeySecretRef == nil {
+			return fmt.Errorf("rootKeySecretRef is not set")


Throw a Terminal error - this is a configuration error and we should move to Failure status.

miyunari mentioned this pull request Apr 12, 2026

fix: guard against nil RootKeySecretRef in TUF init job #1732

Closed

3 tasks

qodo-code-review Bot added Bug fix Tests labels Apr 12, 2026

qodo-code-review Bot reviewed Apr 12, 2026

View reviewed changes

bouskaJ reviewed Apr 13, 2026

View reviewed changes

bouskaJ requested changes Apr 13, 2026

View reviewed changes

osmman added the bug Something isn't working label Apr 13, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix: guard against nil RootKeySecretRef in TUF init job#1733

fix: guard against nil RootKeySecretRef in TUF init job#1733
miyunari wants to merge 2 commits intomainfrom
fix/tuf-init-nil-rootkeysecretref-rebased

miyunari commented Apr 12, 2026

Uh oh!

qodo-code-review Bot commented Apr 12, 2026

File Walkthrough

Uh oh!

qodo-code-review Bot commented Apr 12, 2026 •

edited

Loading

Uh oh!

qodo-code-review Bot Apr 12, 2026

Uh oh!

qodo-code-review Bot commented Apr 12, 2026 •

edited

Loading

Uh oh!

qodo-code-review Bot commented Apr 12, 2026

Uh oh!

bouskaJ Apr 13, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

miyunari commented Apr 12, 2026

Summary

Test plan

Uh oh!

qodo-code-review Bot commented Apr 12, 2026

PR Type

Description

File Walkthrough

Uh oh!

qodo-code-review Bot commented Apr 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Review by Qodo

Uh oh!

qodo-code-review Bot Apr 12, 2026

Choose a reason for hiding this comment

Uh oh!

qodo-code-review Bot commented Apr 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Review by Qodo

Uh oh!

qodo-code-review Bot commented Apr 12, 2026

CI Feedback 🧐

Uh oh!

bouskaJ Apr 13, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

qodo-code-review Bot commented Apr 12, 2026 •

edited

Loading

qodo-code-review Bot commented Apr 12, 2026 •

edited

Loading