introduce caib cancel#228
Conversation
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 4 minutes and 14 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (10)
📝 WalkthroughWalkthroughAdds a cancel feature across CLI, client, server, controller, and types: Changes
Sequence DiagramsequenceDiagram
participant User as User/CLI
participant APIClient as API Client
participant Server as API Server
participant K8s as Kubernetes API
participant Controller as ImageBuild Controller
User->>APIClient: caib image cancel <build-name>
APIClient->>Server: POST /v1/builds/<build-name>/cancel (Bearer token)
Server->>K8s: Get ImageBuild <build-name>
alt not found
Server-->>APIClient: 404 build not found
else found
Server->>Server: Check requester vs requested-by annotation
alt unauthorized
Server-->>APIClient: 403 unauthorized
else authorized
Server->>Server: Check phase ∈ cancellable set
alt not cancellable
Server-->>APIClient: 409 cannot be cancelled
else cancellable
alt has PipelineRun
Server->>K8s: Get PipelineRun
alt exists and not completed
Server->>K8s: Patch PipelineRun.Spec.Status = "Cancelled"
else completed
Server-->>APIClient: 409 already completed
end
end
Server->>K8s: Update ImageBuild.Status -> Phase="Cancelled", CompletionTime=now
Server-->>APIClient: 200 cancelled
K8s->>Controller: ImageBuild updated event
Controller->>K8s: Reconcile terminal cleanup for Cancelled
end
end
end
APIClient-->>User: Confirmation / error
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
internal/controller/imagebuild/controller.go (1)
153-158:⚠️ Potential issue | 🟠 MajorCancelled uploads can leak the upload pod.
At Line 153, cancelled builds only run
cleanupTransientSecrets. If cancellation happens during Uploading, the upload pod is not shut down and can remain running.💡 Proposed fix
- case phaseCancelled, phaseFailed: - // Retry cleanup of any transient secrets that failed to delete. - if err := r.cleanupTransientSecrets(ctx, imageBuild, r.Log); err != nil { - return ctrl.Result{RequeueAfter: secretCleanupRequeue}, nil - } - return ctrl.Result{}, nil + case phaseCancelled: + // Ensure upload pod is stopped if cancellation happened during upload phase. + if err := r.shutdownUploadPod(ctx, imageBuild); err != nil { + log.Error(err, "Failed to shutdown upload pod for cancelled build") + } + if err := r.cleanupTransientSecrets(ctx, imageBuild, r.Log); err != nil { + return ctrl.Result{RequeueAfter: secretCleanupRequeue}, nil + } + return ctrl.Result{}, nil + case phaseFailed: + // Retry cleanup of any transient secrets that failed to delete. + if err := r.cleanupTransientSecrets(ctx, imageBuild, r.Log); err != nil { + return ctrl.Result{RequeueAfter: secretCleanupRequeue}, nil + } + return ctrl.Result{}, nil🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@internal/controller/imagebuild/controller.go` around lines 153 - 158, The cancelled/failed branch currently only calls cleanupTransientSecrets, which can leave the upload pod running; add a call to a cleanup routine that deletes the upload pod (e.g., r.cleanupUploadPod(ctx, imageBuild, r.Log) or r.deleteUploadPodIfExists) inside the case for phaseCancelled and phaseFailed, mirror the error handling used for cleanupTransientSecrets (requeue on error using secretCleanupRequeue or a dedicated requeue duration), and ensure the upload-pod cleanup runs before returning ctrl.Result so cancelled uploads cannot leak pods.
🧹 Nitpick comments (2)
cmd/caib/buildcmd/build.go (1)
840-856: Consider adding a bounded timeout to cancel requests.
RunCancelcurrently usescontext.Background()for the API call. A short timeout would avoid hanging indefinitely on transport stalls.💡 Suggested adjustment
func (h *Handler) RunCancel(_ *cobra.Command, args []string) { - ctx := context.Background() + ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second) + defer cancel() buildName := args[0]🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@cmd/caib/buildcmd/build.go` around lines 840 - 856, RunCancel uses context.Background() which can block indefinitely; replace it by creating a cancellable context with a bounded timeout (e.g., context.WithTimeout) before calling api.CancelBuild in Handler.RunCancel, pass that ctx into api.CancelBuild, and ensure you defer the cancel() to release resources; choose an appropriate short duration (e.g., 5–15s) and handle the context deadline error via the existing h.handleError path.internal/buildapi/server_test.go (1)
415-480: Consider adding an explicitUploadingcancellation test case.
PendingandBuildingare covered, butUploadingis also documented as cancellable; adding that case would close the phase-policy gap.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@internal/buildapi/server_test.go` around lines 415 - 480, Add a new test case mirroring the existing "Pending" and "Building" specs that exercises cancelling an ImageBuild in phase "Uploading": create a build via newCancelTestBuild("Uploading", "") (or with a PipelineRun if your cancellation logic expects one), use newCancelFakeClient to return the fake client, call server.cancelBuild(c, "my-build") and assert HTTP 200, that the ImageBuild Status.Phase becomes "Cancelled", Status.Message equals "Build cancelled by user" and CompletionTime is set; place this alongside the other It(...) blocks so cancel behavior for the "Uploading" phase is explicitly covered.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@cmd/caib/buildcmd/logs.go`:
- Around line 151-155: The cancellation branch in the loop (when st.Phase ==
phaseCancelled) returns an error but skips the centralized error handling used
by other branches; update the branch that currently calls pb.Clear(), prints
"Build was cancelled." and returns fmt.Errorf("build cancelled") to also invoke
h.handleError(...) with the same contextual error (or wrap the fmt.Errorf)
before returning so cancellation flows through the same error handling path as
the timeout/failed cases; reference the st.Phase check for phaseCancelled,
pb.Clear(), the printed message, and h.handleError to locate and modify the code
in logs.go.
In `@internal/buildapi/server.go`:
- Around line 909-931: The code currently proceeds to mark ImageBuild as
Cancelled even when the fetched PipelineRun already completed; change the logic
in the block that handles k8sClient.Get(...) and pipelineRun to check if the
PipelineRun exists and pipelineRun.Status.CompletionTime != nil and, in that
case, abort with c.JSON(http.StatusConflict, ...) (409) instead of falling
through to update build.Status; specifically update the branch that inspects
pipelineRun.Status.CompletionTime (referencing pipelineRun, k8sClient.Get, and
ImageBuild build.Status.Phase) so that a completed PipelineRun returns 409 and
skips modifying build.Status.
- Around line 924-936: The cancel handler sets build.Status.Phase =
phaseCancelled but the log-stream loop still only treats
phaseCompleted/phaseFailed as terminal; update the log-stream exit logic in
shouldExitLogStream (and any callers) to also consider phaseCancelled as a
terminal phase so the /v1/builds/:name/logs polling stops immediately after
cancel. Locate shouldExitLogStream in the same file and add phaseCancelled to
the terminal-phase check (and update any switch/if that compares
build.Status.Phase) so cancelled builds break out the log streaming path.
---
Outside diff comments:
In `@internal/controller/imagebuild/controller.go`:
- Around line 153-158: The cancelled/failed branch currently only calls
cleanupTransientSecrets, which can leave the upload pod running; add a call to a
cleanup routine that deletes the upload pod (e.g., r.cleanupUploadPod(ctx,
imageBuild, r.Log) or r.deleteUploadPodIfExists) inside the case for
phaseCancelled and phaseFailed, mirror the error handling used for
cleanupTransientSecrets (requeue on error using secretCleanupRequeue or a
dedicated requeue duration), and ensure the upload-pod cleanup runs before
returning ctrl.Result so cancelled uploads cannot leak pods.
---
Nitpick comments:
In `@cmd/caib/buildcmd/build.go`:
- Around line 840-856: RunCancel uses context.Background() which can block
indefinitely; replace it by creating a cancellable context with a bounded
timeout (e.g., context.WithTimeout) before calling api.CancelBuild in
Handler.RunCancel, pass that ctx into api.CancelBuild, and ensure you defer the
cancel() to release resources; choose an appropriate short duration (e.g.,
5–15s) and handle the context deadline error via the existing h.handleError
path.
In `@internal/buildapi/server_test.go`:
- Around line 415-480: Add a new test case mirroring the existing "Pending" and
"Building" specs that exercises cancelling an ImageBuild in phase "Uploading":
create a build via newCancelTestBuild("Uploading", "") (or with a PipelineRun if
your cancellation logic expects one), use newCancelFakeClient to return the fake
client, call server.cancelBuild(c, "my-build") and assert HTTP 200, that the
ImageBuild Status.Phase becomes "Cancelled", Status.Message equals "Build
cancelled by user" and CompletionTime is set; place this alongside the other
It(...) blocks so cancel behavior for the "Uploading" phase is explicitly
covered.
🪄 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: Pro
Run ID: 4050a13e-9bd5-47f2-afad-0e6889d54930
📒 Files selected for processing (8)
cmd/caib/buildcmd/build.gocmd/caib/buildcmd/logs.gocmd/caib/image/image.gocmd/caib/runtime_wiring.gointernal/buildapi/client/client.gointernal/buildapi/server.gointernal/buildapi/server_test.gointernal/controller/imagebuild/controller.go
d5856cc to
a516c40
Compare
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
a516c40 to
b66c008
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
internal/buildapi/server_test.go (1)
299-342: Consider sharing setup helpers with the Delete Build context.
originalGetClientFromRequestFn/originalNamespacesave/restore plumbing and thenewFakeClient/newCancelFakeClientbuilders largely duplicate the equivalents in theDelete Buildcontext (lines 112-161). Extracting a sharedBeforeEach/helper at the outerDescribescope (or a small package-private helper likenewTestSchemeClient) would reduce drift as more endpoints are added.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@internal/buildapi/server_test.go` around lines 299 - 342, The test contains duplicated setup/teardown and fake client builders between the "Cancel Build" and "Delete Build" contexts (symbols: originalGetClientFromRequestFn, originalNamespace, newCancelFakeClient, newFakeClient); extract the shared save/restore of getClientFromRequestFn and BUILD_API_NAMESPACE plus a shared fake-client builder (e.g., newTestSchemeClient or a BeforeEach/AfterEach at the outer Describe) and have both contexts call those helpers so the duplicated plumbing is centralized and reused.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@api/v1alpha1/imagebuild_types.go`:
- Around line 216-218: The CRD enum on the ImageBuild status field Phase (field
Phase in type Status in imagebuild_types.go) was extended to include "Cancelled"
but the generated CRD/schema wasn't updated; run the generator to regenerate
DeepCopy methods and CRD manifests and commit the results: run the project
generation targets (e.g. make generate manifests) to update the OpenAPI
validation schema for Status.Phase so the API server accepts "Cancelled", then
review and stage the updated CRD YAML and deepcopy files produced by the
generator.
---
Nitpick comments:
In `@internal/buildapi/server_test.go`:
- Around line 299-342: The test contains duplicated setup/teardown and fake
client builders between the "Cancel Build" and "Delete Build" contexts (symbols:
originalGetClientFromRequestFn, originalNamespace, newCancelFakeClient,
newFakeClient); extract the shared save/restore of getClientFromRequestFn and
BUILD_API_NAMESPACE plus a shared fake-client builder (e.g., newTestSchemeClient
or a BeforeEach/AfterEach at the outer Describe) and have both contexts call
those helpers so the duplicated plumbing is centralized and reused.
🪄 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: Pro
Run ID: 0cc634b5-870f-433e-aedd-036bb809735f
⛔ Files ignored due to path filters (1)
config/crd/bases/automotive.sdv.cloud.redhat.com_imagebuilds.yamlis excluded by!config/crd/bases/**
📒 Files selected for processing (10)
api/v1alpha1/imagebuild_types.gocmd/caib/buildcmd/build.gocmd/caib/buildcmd/logs.gocmd/caib/image/image.gocmd/caib/runtime_wiring.gointernal/buildapi/client/client.gointernal/buildapi/container_builds.gointernal/buildapi/server.gointernal/buildapi/server_test.gointernal/controller/imagebuild/controller.go
✅ Files skipped from review due to trivial changes (1)
- internal/buildapi/container_builds.go
🚧 Files skipped from review as they are similar to previous changes (6)
- cmd/caib/runtime_wiring.go
- internal/buildapi/client/client.go
- cmd/caib/image/image.go
- cmd/caib/buildcmd/build.go
- internal/controller/imagebuild/controller.go
- internal/buildapi/server.go
bkhizgiy
left a comment
There was a problem hiding this comment.
nice addition! will be useful XD
b66c008 to
d38acd5
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
internal/controller/imagebuild/controller.go (2)
159-164:⚠️ Potential issue | 🟠 MajorDelete the upload pod when a build is cancelled during upload.
phaseCancellednow reaches this terminal branch, but only transient secrets are cleaned up. If cancellation happens inUploading, the upload pod is preserved with the ImageBuild and can keep running indefinitely.Proposed fix
case phaseCancelled, phaseFailed: + if imageBuild.Status.Phase == phaseCancelled && imageBuild.Spec.GetInputFilesServer() { + if err := r.shutdownUploadPod(ctx, imageBuild); err != nil { + log.Error(err, "Failed to shutdown upload pod after cancellation") + return ctrl.Result{}, err + } + } // Retry cleanup of any transient secrets that failed to delete. if err := r.cleanupTransientSecrets(ctx, imageBuild, r.Log); err != nil { return ctrl.Result{RequeueAfter: secretCleanupRequeue}, nil }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@internal/controller/imagebuild/controller.go` around lines 159 - 164, When handling the terminal branch for phaseCancelled/phaseFailed in the reconcile (the switch handling these phases around the case with r.cleanupTransientSecrets), also delete the upload pod so a cancelled build in Uploading doesn't leave the pod running; call the existing helper that removes the upload pod (e.g., r.deleteUploadPod(ctx, imageBuild, r.Log) or the equivalent function that deletes the associated Pod) after or before cleanupTransientSecrets, treat any deletion error as transient and requeue (return ctrl.Result{RequeueAfter: secretCleanupRequeue}, err) and otherwise return ctrl.Result{} when both cleanupTransientSecrets and upload-pod deletion succeed.
2103-2111:⚠️ Potential issue | 🟠 MajorPrevent stale reconciles from overwriting
Cancelled.The cancel API can set
Cancelledwhile an older reconcile is still running. SinceupdateStatusrefetches the fresh object but then unconditionally assignsphase, a stale path can move a cancelled build back toBuilding,Failed, orCompleted.Proposed fix
oldPhase := fresh.Status.Phase oldMessage := fresh.Status.Message + if isTerminalPhase(oldPhase) && oldPhase != phase { + return nil + } + fresh.Status.Phase = phase fresh.Status.Message = message🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@internal/controller/imagebuild/controller.go` around lines 2103 - 2111, The updateStatus path unconditionally sets fresh.Status.Phase and can overwrite a user-cancelled build; modify updateStatus (the block that assigns fresh.Status.Phase, fresh.Status.Message and sets StartTime/CompletionTime) to first fetch fresh and then skip changing Phase (and related timestamps/messages) if fresh.Status.Phase == Cancelled (or equals the package constant/enum for cancelled, e.g. phaseCancelled/Cancelled), otherwise proceed with the existing logic; ensure you still set StartTime/CompletionTime only when you actually change the phase (keep checks using phaseBuilding/isTerminalPhase).
♻️ Duplicate comments (1)
cmd/caib/buildcmd/logs.go (1)
151-154:⚠️ Potential issue | 🟠 MajorRoute cancellations through
handleErrorso the CLI exits non-zero.This branch returns an error but skips the centralized error path used by timeout and failed builds, so callers that just return from
Run*can exit successfully after cancellation.Proposed fix
if st.Phase == phaseCancelled { pb.Clear() + cancelErr := fmt.Errorf("build cancelled") fmt.Println("Build was cancelled.") - return fmt.Errorf("build cancelled") + h.handleError(cancelErr) + return cancelErr }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@cmd/caib/buildcmd/logs.go` around lines 151 - 154, The cancellation branch currently prints a message and returns fmt.Errorf("build cancelled") directly (see st.Phase == phaseCancelled, pb.Clear(), fmt.Println("Build was cancelled.")), bypassing the centralized exit behavior; change it to route the cancellation through the shared error handler by clearing the progress (pb.Clear()) then calling handleError with the constructed error (or passing an error value into the same path used for timeouts/failures) instead of printing and returning directly so callers exit non-zero consistently.
🧹 Nitpick comments (1)
internal/buildapi/server_test.go (1)
379-413: Add coverage for already-cancelled builds.The terminal-state cases cover
CompletedandFailed, but notCancelled. Since cancel setsCancelledas terminal, a repeat cancel should also return conflict instead of rewriting status.Suggested test case
It("should return 409 when build has already failed", func() { build := newCancelTestBuild("Failed", "") fakeClient := newCancelFakeClient(build) getClientFromRequestFn = func(_ *gin.Context) (ctrlclient.Client, error) { return fakeClient, nil } @@ Expect(w.Code).To(Equal(http.StatusConflict)) Expect(w.Body.String()).To(ContainSubstring("cannot be cancelled")) }) + + It("should return 409 when build is already cancelled", func() { + build := newCancelTestBuild("Cancelled", "") + fakeClient := newCancelFakeClient(build) + getClientFromRequestFn = func(_ *gin.Context) (ctrlclient.Client, error) { + return fakeClient, nil + } + + w := httptest.NewRecorder() + c, _ := gin.CreateTestContext(w) + c.Request, _ = http.NewRequest(http.MethodPost, "/v1/builds/my-build/cancel", nil) + c.Set("requester", "alice") + + server.cancelBuild(c, "my-build") + + Expect(w.Code).To(Equal(http.StatusConflict)) + Expect(w.Body.String()).To(ContainSubstring("cannot be cancelled")) + })🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@internal/buildapi/server_test.go` around lines 379 - 413, Add a test case mirroring the "Completed" and "Failed" specs to assert a repeat cancel on an already-cancelled build returns 409 and an appropriate message: create a build via newCancelTestBuild("Cancelled", ""), wrap it in newCancelFakeClient, set getClientFromRequestFn to return that fake client, create a gin test context and request as in the other tests, call server.cancelBuild(c, "my-build"), and Expect the response code to Equal(http.StatusConflict) and the body to ContainSubstring("cannot be cancelled").
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@internal/buildapi/server.go`:
- Around line 895-903: The cancel endpoint currently rejects builds whose
build.Status.Phase is empty string; update the switch in the cancellation logic
to treat an empty phase as cancellable (same as phasePending) so new ImageBuilds
that haven't had the controller set the initial phase can still be cancelled;
modify the switch that checks build.Status.Phase (the block handling
phasePending, phaseUploading, phaseBuilding, phasePushing, phaseFlashing) to
include the "" case (or explicitly check build.Status.Phase == "" before the
switch and allow cancellation) so a call to caib image cancel won’t return 409
for newly-created builds.
---
Outside diff comments:
In `@internal/controller/imagebuild/controller.go`:
- Around line 159-164: When handling the terminal branch for
phaseCancelled/phaseFailed in the reconcile (the switch handling these phases
around the case with r.cleanupTransientSecrets), also delete the upload pod so a
cancelled build in Uploading doesn't leave the pod running; call the existing
helper that removes the upload pod (e.g., r.deleteUploadPod(ctx, imageBuild,
r.Log) or the equivalent function that deletes the associated Pod) after or
before cleanupTransientSecrets, treat any deletion error as transient and
requeue (return ctrl.Result{RequeueAfter: secretCleanupRequeue}, err) and
otherwise return ctrl.Result{} when both cleanupTransientSecrets and upload-pod
deletion succeed.
- Around line 2103-2111: The updateStatus path unconditionally sets
fresh.Status.Phase and can overwrite a user-cancelled build; modify updateStatus
(the block that assigns fresh.Status.Phase, fresh.Status.Message and sets
StartTime/CompletionTime) to first fetch fresh and then skip changing Phase (and
related timestamps/messages) if fresh.Status.Phase == Cancelled (or equals the
package constant/enum for cancelled, e.g. phaseCancelled/Cancelled), otherwise
proceed with the existing logic; ensure you still set StartTime/CompletionTime
only when you actually change the phase (keep checks using
phaseBuilding/isTerminalPhase).
---
Duplicate comments:
In `@cmd/caib/buildcmd/logs.go`:
- Around line 151-154: The cancellation branch currently prints a message and
returns fmt.Errorf("build cancelled") directly (see st.Phase == phaseCancelled,
pb.Clear(), fmt.Println("Build was cancelled.")), bypassing the centralized exit
behavior; change it to route the cancellation through the shared error handler
by clearing the progress (pb.Clear()) then calling handleError with the
constructed error (or passing an error value into the same path used for
timeouts/failures) instead of printing and returning directly so callers exit
non-zero consistently.
---
Nitpick comments:
In `@internal/buildapi/server_test.go`:
- Around line 379-413: Add a test case mirroring the "Completed" and "Failed"
specs to assert a repeat cancel on an already-cancelled build returns 409 and an
appropriate message: create a build via newCancelTestBuild("Cancelled", ""),
wrap it in newCancelFakeClient, set getClientFromRequestFn to return that fake
client, create a gin test context and request as in the other tests, call
server.cancelBuild(c, "my-build"), and Expect the response code to
Equal(http.StatusConflict) and the body to ContainSubstring("cannot be
cancelled").
🪄 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: Pro
Run ID: 91a3c879-ac81-4689-a300-caece90e637d
⛔ Files ignored due to path filters (1)
config/crd/bases/automotive.sdv.cloud.redhat.com_imagebuilds.yamlis excluded by!config/crd/bases/**
📒 Files selected for processing (10)
api/v1alpha1/imagebuild_types.gocmd/caib/buildcmd/build.gocmd/caib/buildcmd/logs.gocmd/caib/image/image.gocmd/caib/runtime_wiring.gointernal/buildapi/client/client.gointernal/buildapi/container_builds.gointernal/buildapi/server.gointernal/buildapi/server_test.gointernal/controller/imagebuild/controller.go
✅ Files skipped from review due to trivial changes (1)
- cmd/caib/runtime_wiring.go
🚧 Files skipped from review as they are similar to previous changes (4)
- internal/buildapi/container_builds.go
- internal/buildapi/client/client.go
- api/v1alpha1/imagebuild_types.go
- cmd/caib/image/image.go
d38acd5 to
a4c3c68
Compare
Allow cancellation of builds Signed-off-by: Benny Zlotnik <bzlotnik@redhat.com> Assisted-by: claude-opus-4.6
a4c3c68 to
1f710a7
Compare
Allow cancellation of builds
Summary
Related Issues
Type of Change
Testing
make test)make lint)make manifests generate)Summary by CodeRabbit
New Features
caib image cancel <build-name>to cancel in‑progress builds from the CLI.Improvements
Tests