Skip to content

Conversation

@csviri
Copy link
Collaborator

@csviri csviri commented Sep 13, 2025

See related issue

@openshift-ci openshift-ci bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Sep 13, 2025
@csviri csviri mentioned this pull request Sep 13, 2025
@csviri csviri linked an issue Sep 13, 2025 that may be closed by this pull request
@csviri csviri changed the title feat: expectation pattern support [WIP] feat: expectation pattern support Sep 22, 2025
@openshift-merge-robot openshift-merge-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Sep 25, 2025
@openshift-merge-robot openshift-merge-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Sep 29, 2025
@csviri csviri force-pushed the expectation-simple branch from ca4c8a2 to c3c33bc Compare October 16, 2025 11:11
@csviri csviri changed the title [WIP] feat: expectation pattern support feat: expectation pattern support Oct 16, 2025
@csviri csviri marked this pull request as ready for review October 16, 2025 14:40
@openshift-ci openshift-ci bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Oct 16, 2025
@openshift-ci openshift-ci bot requested review from metacosm and xstefank October 16, 2025 14:40
@openshift-merge-robot openshift-merge-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Oct 18, 2025
@csviri csviri force-pushed the expectation-simple branch from 838d1a3 to 4c1de74 Compare October 23, 2025 10:40
@openshift-merge-robot openshift-merge-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Oct 23, 2025
Signed-off-by: Attila Mészáros <a_meszaros@apple.com>
Signed-off-by: Attila Mészáros <a_meszaros@apple.com>
Signed-off-by: Attila Mészáros <a_meszaros@apple.com>
Signed-off-by: Attila Mészáros <a_meszaros@apple.com>
Signed-off-by: Attila Mészáros <a_meszaros@apple.com>
Signed-off-by: Attila Mészáros <a_meszaros@apple.com>
Signed-off-by: Attila Mészáros <a_meszaros@apple.com>
Signed-off-by: Attila Mészáros <a_meszaros@apple.com>
Signed-off-by: Attila Mészáros <a_meszaros@apple.com>
Signed-off-by: Attila Mészáros <a_meszaros@apple.com>
Signed-off-by: Attila Mészáros <a_meszaros@apple.com>
Signed-off-by: Attila Mészáros <a_meszaros@apple.com>
@csviri csviri force-pushed the expectation-simple branch from cfde8f5 to 603ac9d Compare October 24, 2025 12:52
import io.fabric8.kubernetes.api.model.HasMetadata;

record RegisteredExpectation<P extends HasMetadata>(
LocalDateTime registeredAt, Duration timeout, Expectation<P> expectation) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

registeredAt should probably not be left over to the caller, we can set it in the constructor

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure how do you mean it, you mean the user should provide the regsiteredAt?


assertThat(result.isExpectationPresent()).isTrue();
assertThat(result.isTimedOut()).isTrue();
assertThat(expectationManager.isExpectationPresent(configMap)).isTrue();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TBH I find this a little strange. Maybe timedout expectation should be handled differently. Because is it present after it timeouts?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea is that we preserv that state, since user for sure want to handle that situation when the expectation is timed out, so we dont't remove timed out expectation. This is what you mean?

expectationManager.setExpectation(configMap, Duration.ofMinutes(5), expectation);
Optional<String> name = expectationManager.getExpectationName(configMap);

assertThat(name).contains(expectedName);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

equals?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's an optional, so I guess this is right.

expectationManager.setExpectation(configMap, Duration.ofMinutes(5), expectation);
assertThat(expectationManager.isExpectationPresent(configMap)).isTrue();

expectationManager.cleanup(configMap);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer removeExpectation

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, sounds a bit better, thx, changed!

return UpdateControl.noUpdate();
}
} else {
// checks the expectation if it is fulfilled also removes it,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same fix as in the docs

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure what do you mean... pls ellaborate

csviri and others added 6 commits November 1, 2025 01:08
Co-authored-by: Martin Stefanko <xstefank122@gmail.com>
Co-authored-by: Martin Stefanko <xstefank122@gmail.com>
Co-authored-by: Martin Stefanko <xstefank122@gmail.com>
Co-authored-by: Martin Stefanko <xstefank122@gmail.com>
Co-authored-by: Martin Stefanko <xstefank122@gmail.com>
Signed-off-by: Attila Mészáros <a_meszaros@apple.com>
@csviri
Copy link
Collaborator Author

csviri commented Nov 1, 2025

thank you @xstefank for all the fixes in javadocs and other suggestions!!

@csviri csviri requested a review from xstefank November 1, 2025 00:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Support for expectations pattern

4 participants