Change:
} return v } <ins> // convertCelTypeToDeclType converts a cel.Type to DeclType, for the use of // the TypeProvider and the cost estimator. // List and map types are created on-demand with their parameters converted recursively. func convertCelTypeToDeclType(celType *cel.Type) *apiservercel.DeclType { if celType == nil { return apiservercel.DynType } switch celType { case cel.AnyType: return apiservercel.AnyType case cel.BoolType: return apiservercel.BoolType case cel.BytesType: return apiservercel.BytesType case cel.DoubleType: return apiservercel.DoubleType case cel.DurationType: return apiservercel.DurationType case cel.IntType: return apiservercel.IntType case cel.NullType: return apiservercel.NullType case cel.StringType: return apiservercel.StringType case cel.TimestampType: return apiservercel.TimestampType case cel.UintType: return apiservercel.UintType default: if celType.HasTrait(traits.ContainerType) && celType.HasTrait(traits.IndexerType) { parameters := celType.Parameters() switch len(parameters) { case 1: elemType := convertCelTypeToDeclType(parameters[0]) return apiservercel.NewListType(elemType, -1) case 2: keyType := convertCelTypeToDeclType(parameters[0]) valueType := convertCelTypeToDeclType(parameters[1]) return apiservercel.NewMapType(keyType, valueType, -1) } } return apiservercel.DynType } } </ins>

Discussion:
Variables field is to ValidatingAdmissionPolicy in 1.28. Currently the usage of variables would expect a operator associated. e.g. (thanks to Mariam Fahmy for raising the issue) Above will fail with error: Meanwhile the will pass. The reason is when variables be evaluated to non dyn type(like bool or string), it will require special handling(like casting) since we use dyn type everywhere. It might confuse user.
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/triage accepted /sig api-machinery /cc
Tests I'd expect to see verify this behavior: PASS: A variable is of type bool, an expression returns the variable PASS: A variable is of type string, a messageExpression returns the variable PASS: A variable is of type dyn, at runtime the dyn is a bool, an expression returns the variable PASS: A variable is of typedyn, at runtime the dyn is a string, an messageExpression returns the variable PASS: A expression is of type dyn, at runtime the dyn is of type bool PASS: A messageExpression is of type dyn, at runtime the dyn is of type string COMPILE ERROR: A variable is of type bool, an expression tries to perform a non-bool (e.g. string replace) operation on the variable, this should resultsin a compile error COMPILE ERROR: A variable is of type string, an expression tries to perform a non-string (e.g. less than) operation on the variable, this should result in a compile error RUNTIME ERROR: A variable is of type dyn, at runtime the dyn is a bool, an expression tries to perform a non-bool (e.g. string replace) operation on the variable, this should result in a runtime error I'd also expect to see some cases covering variables of other types (maps, lists, duration, quantity, ...) to make sure we're over-fitting for bool and string.
/retitle ValidatingAdmissionPolicy: variable expression type not recognized as return type in expression that evaluates the variable
/assign