feat: cascade delete all children on pipeline delete#1112
Open
ishtoo1 wants to merge 1 commit into
Open
Conversation
1 task
Go Coverage Report (Bazel)Total Coverage: 63.4% Coverage Policy:
|
cece21f to
c42691b
Compare
c2f628c to
a97b06a
Compare
c42691b to
424965e
Compare
a97b06a to
17a9b4c
Compare
424965e to
6c465c0
Compare
17a9b4c to
1a4d392
Compare
6c465c0 to
1404e77
Compare
1a4d392 to
a7ac07c
Compare
1404e77 to
8276079
Compare
a7ac07c to
1abceee
Compare
What: - Replace placeholder with DeleteAllTriggerRuns + DeleteAllPipelineRuns calls (fatal errors cause requeue, best-effort revision cleanup follows). - Wire revision.Manager into the Pipeline Reconciler (defaults to NoOpManager) and invoke DeleteAllRevisions after children are deleted, mirroring the deployment controller's pattern. - Remove finalizer only after all children successfully deleted. - Add TestCascadeDelete_AllTerminal, TestCascadeDelete_RevisionsCleaned, and TestCascadeDelete_SkippedPRsTerminal tests. Why: - Users running `ma pipeline delete` previously had to manually kill active TriggerRuns/PipelineRuns, wait for terminal states, and delete each child CR one by one. Now the controller does this transparently when a Pipeline CR is marked for deletion. How to test: - bazel test //go/components/pipeline/... (all new regression tests pass). - Manually: `ma pipeline delete` against a pipeline with terminal children and observe that child CRs are removed before the pipeline CR disappears. Breaking changes: - `ma pipeline delete <pipeline>` now cascades to all child TriggerRuns, PipelineRuns, and Revisions belonging to the pipeline. Every child CR is deleted along with the pipeline. There is no undo. - Deletion is asynchronous (finalizer removal happens after cascade completes). If you relied on `ma pipeline delete` returning once the Pipeline CR is actually gone from etcd, you now need to poll `ma pipeline get` or similar until NotFound. - Any external tooling that previously issued its own cleanup for TRs/PRs/ Revisions should be simplified: those children are now cleaned up by the controller. Double-delete is safe (NotFound is tolerated) but unnecessary. Co-Authored-By: Oz <oz-agent@warp.dev>
8276079 to
ca5b4c3
Compare
1abceee to
c248111
Compare
1 task
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What type of PR is this? (check all applicable)
What changed?
DeleteAllTriggerRuns+DeleteAllPipelineRuns(fatal errors requeue).revision.Managerinto the Pipeline Reconciler (defaults torevision.NewNoOpManager()) and callDeleteAllRevisions(ns, name, \"Pipeline\")after children are removed. Mirrors the deployment controller's pattern.TestCascadeDelete_AllTerminal,TestCascadeDelete_RevisionsCleaned, andTestCascadeDelete_SkippedPRsTerminal.Why?
Addressing #1091.
Users running
ma pipeline deletepreviously had to manually kill active TriggerRuns/PipelineRuns, wait for terminal states, and delete each child CR one by one. This PR completes the controller-side cascade so the delete is a single atomic operation from the user's perspective.How did you test it?
bazel test //go/components/pipeline/...— all new regression tests pass.Manually against a pipeline with terminal children:
ma pipeline deleteremoves every child CR before the pipeline CR disappears.End-to-end behavior of the full cascade-delete stack is verified on a sandbox cluster; results are attached on docs: document pipeline cascade delete behavior #1114.
Potential risks
ma pipeline delete <pipeline>now cascades to all child TriggerRuns, PipelineRuns, and Revisions belonging to the pipeline. Every child CR is deleted. No undo.deletewill continue to work, but anything that assumed the pipeline was gone as soon asma pipeline deletereturned will observeTerminatingfor as long as the cascade runs.IsNotFoundis tolerated).Release notes
⚠ Breaking:
ma pipeline deletenow cascades to all TriggerRuns, PipelineRuns, and Revisions belonging to the pipeline. Deletion is asynchronous — the pipeline CR remains inTerminatinguntil the controller finishes the cascade.Documentation Changes
User-facing documentation lands in
feat/cascade-delete-docs.Stacked on top of #1111.