• Kubernetes Submit Queue's avatar
    Merge pull request #41151 from ahakanbaba/tpr-unit-tests · 8ceb0c40
    Kubernetes Submit Queue authored
    Automatic merge from submit-queue (batch tested with PRs 41937, 41151, 42092, 40269, 42135)
    
    Add a unit test for idempotent applys to the TPR entries.
    
    The test in apply_test follows the general pattern of other tests.
    We load from a file in test/fixtures and mock the API server in the
    function closure in the HttpClient call.
    The apply operation expects a last-modified-configuration annotation.
    That is written verbatim in the test/fixture file.
    
    References #40841
    
    
    
    **What this PR does / why we need it**:
    Adds one unit test for TPR's using applies. 
    
    **Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes #
    References: 
    https://github.com/kubernetes/features/issues/95
    https://github.com/kubernetes/kubernetes/issues/40841#issue-204769102
    
    
    **Special notes for your reviewer**:
    
    I am not super proud of the tpr-entry name. 
    But I feel like we need to call the two objects differently. 
    The one which has Kind:ThirdPartyResource 
    and the one has Kind:Foo. 
    
    Is the name "ThirdPartyResource" used interchangeably for both ? I used tpr-entry for the Kind:Foo object.
    
    Also I !assume! this is testing an idempotent apply because the last-applied-configuration annotation is the same as the object itself. 
    
    This is the state I see in the logs of kubectl if I do a proper idempotent apply of a third party resource entry. 
    
    I guess I will know more once I start playing around with apply command that change TPR objects. 
    
    **Release note**:
    
    ```release-note
    ```
    8ceb0c40
Name
Last commit
Last update
..
BUILD Loading commit data...
fake.go Loading commit data...