<div dir="ltr"><div>Same could be achieved by annotating classes with JUnit @Category(InvocationIssue.class).<br><br></div><div>Then you can: <br> - run only InvocationIssue by specifying -Dgroups=InvocationIssue<br> - run all tests except of InvocationIssue by specifying -DexcludedGroups=InvocationIssue<br></div><div> - run all tests by omitting any additional system property<br></div><div><br></div>Advandtage of @Category is you can annotate test method as well.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 31, 2017 at 4:14 PM, Kabir Khan <span dir="ltr"><<a href="mailto:kabir.khan@jboss.com" target="_blank">kabir.khan@jboss.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">><br>
> On 31 Jan 2017, at 15:09, Jason T. Greene <<a href="mailto:jason.greene@redhat.com">jason.greene@redhat.com</a>> wrote:<br>
><br>
> How about the tests are changed to require a sys prop. That way you don't need a branch.<br>
<br>
</span>So rather than @Ignore we add something like<br>
<br>
@BeforeClass<br>
public static checkRunInvocationTests() {<br>
//WFLY-XXXX<br>
Assume.assumeTrue(System.<wbr>getProperty("wildfly.temp.<wbr>disabled-invocation"))<br>
<span class="">}<br>
<br>
><br>
>> On Jan 31, 2017, at 9:07 AM, Jason T. Greene <<a href="mailto:jason.greene@redhat.com">jason.greene@redhat.com</a>> wrote:<br>
>><br>
>> I agree with this approach but we need a way to group these failures in such a way that we know whether or not a change has regressions.<br>
</span>Can you elaborate a little bit?<br>
<div class="HOEnZb"><div class="h5">>><br>
>>> On Jan 31, 2017, at 9:03 AM, Kabir Khan <<a href="mailto:kabir.khan@jboss.com">kabir.khan@jboss.com</a>> wrote:<br>
>>><br>
>>> Hi,<br>
>>><br>
>>> The new invocation library, which is the basis of for the ejb client etc. is currently developed in a branch. There are still about 130-140 test failures, but the team feels it is time to merge to wildfly master at some stage later this week. This will get more visibility of the failures and also lower the barrier of entry for whoever can jump in and help fix the failures.<br>
>>><br>
>>> Are there any objections to merging this?<br>
>>><br>
>>>> From my point of view we would need to @Ignore the failing tests since there are enough transient failures in our testsuite to make it hard to find usual suspects if the number of failed tests is large. We could set up another CI job against a branch which is master with the @Ignores reverted, and I could keep that up to date as I merge to master, so that we get a good picture of the current testsuite failures.<br>
>>><br>
>>> Thanks,<br>
>>><br>
>>> Kabir<br>
>>> ______________________________<wbr>_________________<br>
>>> wildfly-dev mailing list<br>
>>> <a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
>>> <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/wildfly-dev</a><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> wildfly-dev mailing list<br>
>> <a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/wildfly-dev</a><br>
<br>
<br>
______________________________<wbr>_________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/wildfly-dev</a><br>
</div></div></blockquote></div><br></div>