Skip to content
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

Merged
merged 3 commits into from
Nov 27, 2024

Conversation

Vlatombe
Copy link
Member

@Vlatombe Vlatombe commented Nov 25, 2024

Plays nicely with Awaitability as well as in combination with other matchers.

Testing done

Submitter checklist

  • Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
  • Ensure that the pull request title represents the desired changelog entry
  • Please describe what you did
  • Link to relevant issues in GitHub or Jira
  • Link to relevant pull requests, esp. upstream and downstream changes
  • Ensure you have provided tests - that demonstrates feature works or fixes the issue

Plays nicely with Awaitability as well as in combination with other matchers.
@Vlatombe Vlatombe changed the title Provide Hamcrest matchers as alternatives to built-in JenkinsRule Provide Hamcrest matchers as alternatives to built-in JenkinsRule run assertions Nov 25, 2024
@Vlatombe Vlatombe requested a review from jglick November 25, 2024 13:04
Copy link
Member

@timja timja left a 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<?, ?>> {
Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member Author

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

Copy link
Member

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 😢

Copy link
Member Author

Choose a reason for hiding this comment

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

Copy link
Member Author

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"));

?

Copy link
Member

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.

src/test/java/jenkins/test/RunMatchersTest.java Outdated Show resolved Hide resolved
private static class CompletedRunMatcher extends TypeSafeMatcher<Run<?, ?>> {
@Override
protected boolean matchesSafely(Run<?, ?> run) {
return !run.isLogUpdated();
Copy link
Member

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.
could be deleted and that method could also suggest using this matcher.

@Vlatombe
Copy link
Member Author

Relaunching CI

@Vlatombe Vlatombe closed this Nov 27, 2024
@Vlatombe Vlatombe reopened this Nov 27, 2024
@Vlatombe Vlatombe enabled auto-merge November 27, 2024 14:30
@Vlatombe Vlatombe merged commit 8f64d70 into jenkinsci:master Nov 27, 2024
15 checks passed
@Vlatombe Vlatombe deleted the runMatchers branch November 27, 2024 16:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants