-
Notifications
You must be signed in to change notification settings - Fork 515
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
clean eunit and ct #972
Comments
sounds like |
It isn't about number of characters it is about discoverability. If it is an option on |
it would, but then if I'm running a different tool, then there's no option for it and we're stuck adding arguments forever. It might be better for |
I'm not sure what a different tool would matter. If it is based on tests compiled as extra src to the test profile it would be deleted just the same as eunit and common test beams. And if there is more to clean then it would have to provide a |
What I'm saying is not tool-related. It's that if I'm running test under a different compiler profile for example (where The current failure of the |
Then not sure what is wrong with |
that would be fine. That's up to the provider and I like it more than |
command line options already supported by eunit/ct complicate this if a user does: $ rebar3 ct --dir protocol they will need to do: $ rebar3 ct clean --dir protocol additionally, i think extending |
I've put the 3.0.0 milestone on this since we should make a decision before cutting a final release if it risks breaking backwards compatibility. |
Crap, @talentdeficit has a good point. But I don't know that I like |
i think we should reconsider having |
Currently the only way to do this is
rebar3 as test clean
. Maybe we should extend either theeunit
andct
providers ho haveclean
commands or extendclean
to have a--tests
option?The text was updated successfully, but these errors were encountered: