Problem
CEL rules that reference oldSelf (transition rules) only fire on update. The API server skips them on create because there's no prior object to compare against.
crossplane resource validate validates resources with no way to supply prior versions, so it always exercises the create path. There's no way to test immutability constraints or other transition rules with the current CLI.
Proposed change
Add an --old <sources> flag that mirrors the existing <resources> argument (comma-separated files, directories, or - for stdin):
crossplane resource validate <extensions> <resources> [--old <sources>]
The CLI would match each old object to its corresponding new object by kind/name/namespace, then pass the pair as (obj, oldObj) into the validation call. This triggers update validation instead of create validation and populates oldSelf in CEL rules. Resources with no matching old object fall back to the create path as today.
The Kubernetes CEL library already handles (obj, oldObj) pairs, so this should only require a CLI change to surface it.
Problem
CEL rules that reference
oldSelf(transition rules) only fire on update. The API server skips them on create because there's no prior object to compare against.crossplane resource validatevalidates resources with no way to supply prior versions, so it always exercises the create path. There's no way to test immutability constraints or other transition rules with the current CLI.Proposed change
Add an
--old <sources>flag that mirrors the existing<resources>argument (comma-separated files, directories, or-for stdin):The CLI would match each old object to its corresponding new object by kind/name/namespace, then pass the pair as
(obj, oldObj)into the validation call. This triggers update validation instead of create validation and populatesoldSelfin CEL rules. Resources with no matching old object fall back to the create path as today.The Kubernetes CEL library already handles
(obj, oldObj)pairs, so this should only require a CLI change to surface it.