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

test --tests doesn't work properly after barclay update #924

Closed
lbergelson opened this issue Sep 12, 2017 · 3 comments
Closed

test --tests doesn't work properly after barclay update #924

lbergelson opened this issue Sep 12, 2017 · 3 comments
Assignees

Comments

@lbergelson
Copy link
Member

Bug Report

Affected tool(s)

running tests manually on the command line

Affected version(s)

  • [ x ] Latest public release version [version?]
  • [ x ] Latest development/master branch as of [date of test?]

Description

Running

./gradlew tests --tests "*<SomeTestClass>*"

or

./gradlew tests -Dtest.single=<SomeTestClass>

should restrict the tests to only run the test class you explicitly asked for.

Since the barclay introduction it runs all the tests and then the one you asked for. This seems to be because the new gradle test task depends on the barclayTest task. So it first executes that task which runs all the tests and then runs your restricted test set after that.

The workaround is to run ./gradlew legacyTest --tests "*<SomeTestClass>*" which will only run one set of tests.

I would have expected that the --tests and -Dtest.single parameters are propagated to all tasks of type test, so I'm not sure why they're not being respected by barclayTest when run as a prerequisite for test

Seems like we need to dive into the gradle and figure out what's going on. In the meantime, use the barclayTest and legacyTest tasks instead of test when invoking on the command line.

@lbergelson
Copy link
Member Author

@eitanbanks Here's the ticket for what we were talking about yesterday.

@kbergin
Copy link
Contributor

kbergin commented Apr 12, 2019

It seems this has been addressed via #984

@kbergin kbergin closed this as completed Apr 12, 2019
@cmnbroad
Copy link
Contributor

@kbergin I assume you meant to refer to samtools/htsjdk#984, which is an htsjdk issue that has a similar manifestation but a different cause. AFAIK this issue still exists in Picard, although it is a duplicate of #1211. Finally, note that these issues would be eliminated if we moved forward with #1120.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants