-
Notifications
You must be signed in to change notification settings - Fork 130
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide Hamcrest matchers as alternatives to built-in JenkinsRule run assertions #878
Conversation
Plays nicely with Awaitability as well as in combination with other matchers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❤️
} | ||
} | ||
|
||
private static class RunLogMatcher extends TypeSafeMatcher<Run<?, ?>> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about waitForMessage
? This has special behavior for a completed build; not sure if that can be carried over to Awaitility.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It has a fail-early mechanism in case a build is complete, but I don't see how to replicate that using Awaitibility and matchers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess something like
await().until(b, completed());
assertThat(b, logContains("foo"));
would be equivalent to the current waitForMessage
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, because waitForMessage
can be used to wait for a line in a running build.
I was just wondering if there was something in Awaitility that a matcher can use to indicate that not only does the condition not match now, we can be sure it will not match later. https://javadoc.io/static/org.awaitility/awaitility/4.2.2/org/awaitility/core/FailFastCondition.html maybe? No Javadoc 😢
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So something like
await().failFast(() -> !b.isLogUpdated()).until(() -> b, logContains("foo"));
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, that forces the tricky logic to be put into the call site, and only works for a message which you expect to be printed in a running build. I was hoping for something that could be built into the harness that would provide the same functionality as waitForMessage
but integrated into Awaitility: pass if the message appears; fail immediately if the build terminates without the message ever appearing.
private static class CompletedRunMatcher extends TypeSafeMatcher<Run<?, ?>> { | ||
@Override | ||
protected boolean matchesSafely(Run<?, ?> run) { | ||
return !run.isLogUpdated(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I think
// Could be using com.jayway.awaitility:awaitility but it seems like overkill here. |
Relaunching CI |
Plays nicely with Awaitability as well as in combination with other matchers.
Testing done
Submitter checklist