Run rez tests on current package

[herronelou]

Hello.
When I want to run rez-build or rez-release, I cd to my package dev location, and simply type rez build --install or rez release.
However, if I want to run the manual tests, I need to first build or release, then type `rez test {my_package_name} {test_to_run}.

Since I'm in the package directory already, I wish I could simply type rez test {test_to_run} and it would kick off the tests (possibly a build too if required).

Is there a different way that I don't know about?

[ColinKennedy]

There was an attempt to add rez-test ., to indicate the current directory's packages's tests.

#759

However if you read some of the follow-up PR notes, apparently rez-test . wasn't looked at too favorably. Though personally I'd like it to be added, for various reasons. In short, right now, your only choice is rez-test foo {test_to_run}, unless you wrap rez-test to auto-provide the package name. I did that as part of a larger script over here https://github.com/ColinKennedy/rez-scripts/blob/master/bin/rt

[nerdvegas]

There's a few things to unload here. In short the problem is ambiguity. Let's say I'm in my pkg dev folder (foo-1.0.0) and I run `rez-test {test_to_run}`. What should that actually do? Consider the options: * it should do the equivalent to `rez-test foo==1.0.0 {test_to_run}`. Ok, but there's no guarantee that the foo-1.0.0 it finds actually matches the current state of your dev package. It doesn't even guarantee it's the same package at all (it will just find whatever foo is one packages_path). * it should do as per above, but implicitly build/install the package if required. Bad idea. Not only is an implicit build just a generally bad idea (a build is a potentially big thing, and big things shouldn't ever be implicit) - you also are now forcing rez-test to have to inherit all the same cli args as rez-build - if it's gonna build, it needs to afford the user the same control. This would cause a lot of redundancy and, imo, confusion. * it should just run the test on the local, non-built source. Well, there's no guarantee that the package is in a functional state if it hasn't been built. Only a subclass of tests - a new type of test - would be allowed to run on non-built source (such as a linter). I actually think this take makes the most sense - we introduce a new "source only" kind of test, and the way to invoke them is to use `rez-test` and not specify PKG. But, this is not the same as what you're asking for. In short, having rez-test infer the package from cwd suggests that you're testing what's in cwd, and there is just no guarantee of that. So while convenient, I think it would be misleading, and misleading things cause tickets, and I don't like tickets :)

…

On Wed, Jun 22, 2022 at 5:28 AM Erwan Leroy ***@***.***> wrote: Hello. When I want to run rez-build or rez-release, I cd to my package dev location, and simply type rez build --install or rez release. However, if I want to run the manual tests, I need to first build or release, then type `rez test {my_package_name} {test_to_run}. Since I'm in the package directory already, I wish I could simply type rez test {test_to_run} and it would kick off the tests (possibly a build too if required). Is there a different way that I don't know about? — Reply to this email directly, view it on GitHub <#1335>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMOUSTMACHMUQV453MHVDLVQIJW3ANCNFSM5ZNQAEAQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[herronelou]

Yeah makes sense. How about the other way around, have a test arg on the build command?
rez-build --install -test lint

[JeanChristopheMorinPerso]

The main idea is kind of described in #665. Basically, we need an --interactive flag and --inplace. The workflow would look like:

1. rez-build -ci to build your package
2. rez-test . <test-name> --interactive, to enter the environment of the test
3. rez-test <test-name> --inplace, to actually run the specified test in the current environment
4. rez-build -ci to update your build.
5. Repeat step 3 and 4 until you are happy with your test target.

Or something like that.