fix(scope): regenerate only the in-scope deployment's manifests, not all#136
Merged
Merged
Conversation
process_project scoped its namespace/resource/clone steps to `targets`, but called _process_application_manifests(deployment_name) and create_argocd_resources(deployment_name) with the *singular* arg -- which is None on the plural-scoped path -- so a scoped op (e.g. an upsert of one deployment) regenerated EVERY deployment's manifest + ArgoCD folders. That rewrote unrelated deployments and, racing a concurrent delete, resurrected the deleted deployment (pr-32) and produced delete/modify git conflicts. - _process_application_manifests + create_argocd_resources (and its create_repository_secrets / create_app_projects / create_applications) now accept deployment_names and filter via get_deployments; both call sites in process_project pass `targets`. - handle_add_component scopes its reprocess to the affected deployment(s). - AST regression guard that both calls receive deployment_names. Also a perf win: a single-deployment op regenerates one deployment's manifests + SOPS secrets instead of all N. The git add -A whole-tree commit (the amplifier that turns any residual drift into a lost-update) is left for a separate, defense-in-depth change.
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
1 participant
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.
The bug (root cause of the pr-32 resurrection)
process_projectscoped its namespace, resource, and clone steps to the resolvedtargets, but called:On the plural-scoped path (
deployment_names=['production'],deployment_name=None) both receivedNoneand regenerated every deployment's manifest + ArgoCD folders. So a scoped upsert ofproductionrewrotepr-32's folders, which — racing a concurrent delete of pr-32 — produced the delete/modify git conflict and resurrected pr-32 (lost update).Fix
_process_application_manifestsandcreate_argocd_resources(+ itscreate_repository_secrets/create_app_projects/create_applications) now takedeployment_namesand filter viaget_deployments. Bothprocess_projectcall sites passtargets.handle_add_componentnow scopes its reprocess to the affected deployment(s) (it had the list but dropped it) — siblinghandle_add_component_to_deploymentalready did this.deployment_names(fails on the pre-fix code).Effect
Audited clean / out of scope
handle_refresh_project,handle_add_service,create_kustomization_fileslegitimately stay project-wide.commit_and_pushusesgit add -A(whole tree). With this fix only the scoped files change, so it's no longer the lost-update vector — but scoping the staging too is worth a follow-up. The general concurrency safety net is Task queue: dedup/coalesce redundant jobs per project/deployment (level-triggered reconcile) #127.976 relevant tests pass; ruff + pyright clean.