Codecov Report

Merging #2986 into main will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main    #2986   +/-   ##
=======================================
  Coverage   75.03%   75.04%           
=======================================
  Files          90       90           
  Lines        5869     5871    +2     
=======================================
+ Hits         4404     4406    +2     
  Misses       1371     1371           
  Partials       94       94           

FYI this tags the wrong issue

This reverts the switch to Kubernetes semantic equality from #2853

I think that a better fix might be to add the v1.DetailedCondition type to the equality funcs that we use for this comparison. That retains the special handling that api-machinery has for existing Kubernetes types.

var equalities = conversion.Equalities{equality.Semantic}

equalities.AddFunc(func(a, b contourv1.DetailedCondition) bool{
        ...
})

That said, I don't see any practical issues with landing this and following up.

But will adding the type still skip that field? That's the goal here, and why we went with cmp which is used in other places.

But will adding the type still skip that field? That's the goal here, and why we went with cmp which is used in other places.

Looking at the way the interfaces work, you would add your own comparator that skips or flattens the relevant fields (e.g. the time comparison is flattened to UTC). cmp doesn't do the same thing as semantic equality AFAICT; trade-offs in both directions.

FWIW in Knative we define a VolatileTime type, which we exclude from semantic equality, which we use exclusively (I think) for LastTransitionTime.

We define our common condition type here: https://github.com/knative/pkg/blob/21cb070a8b050ec23100078e89df11d67444350c/apis/condition_types.go#L76

We also have https://github.com/projectcontour/contour/blob/main/internal/contour/handler.go#L179-L183 which would need a custom comparer if we want to migrate that to equality.Semantic.DeepEqual.

@stevesloka do you want to merge this as-is for now (@jpeach was OK with that too) and do a follow-up to fully switch compare libraries?

@skriss let's just land this as-is. I think we should chat about how to best approach the solution. I like Knavtive's approach that @mattmoor linked, it removes the extra need to understand that this field is different for other comparisons, but should chat about this a bit before making that change.