Clean up no longer present test suites from _build by 4tyTwo · Pull Request #2626 · erlang/rebar3 · GitHub
More Web Proxy on the site http://driver.im/
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The reason will be displayed to describe this comment to others. Learn more.
The test you're looking here though might be the profile of the path, which would not be accurate in all cases. For example, you might get test+demo if you ran rebar3 as demo ct
We don't run tests on deps, just on top-level apps, which can be found with rebar_state:project_apps(State) (which you can then expand with rebar_app_info:out_dir/1 to get the app's path in _build), so that should cut down the search space.
Additionally, in umbrella applications where a top-level test/ directory exists, the path should be _build/<profile>/extras/test/.
The last final weird case is visible in rebar3. We have some integration suites that run only on Linux that can be called by running rebar3 as systest ct. The directories can be seen in:
→ ls _build/systest+test/lib/rebar/
ebin include priv src systest test
where test cases exist both in systest/ and in test/.
Common test integration is really messy, and my understanding/idea is that we should be able to take the {dir, ...} entries and plug them onto the out_dir(AppInfo) result to get all the entries, plus the extras path if it exists.
The reason will be displayed to describe this comment to others. Learn more.
my understanding/idea is that we should be able to take the {dir, ...} entries and plug them onto the out_dir(AppInfo)
While I can see it working, I can't think of an actually nice way of doing it. I'll try giving it another thought again
This last case when it is possible to provide arbitrary directory which will contain test suites is kind of tricky to work around. My immediate solution would be just looking for .*_SUITE.erl files recursively in both extras and _build/PROFILE/lib/APP (excluding ebin, src, priv and include I guess).
Can you spot any obvious issues with that? My concern is that I'm not sure if any not test .erl files can exist outside the aforementioned 4 directories and therefore be in danger of being affected
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The
test
you're looking here though might be the profile of the path, which would not be accurate in all cases. For example, you might gettest+demo
if you ranrebar3 as demo ct
We don't run tests on deps, just on top-level apps, which can be found with
rebar_state:project_apps(State)
(which you can then expand withrebar_app_info:out_dir/1
to get the app's path in_build
), so that should cut down the search space.Additionally, in umbrella applications where a top-level
test/
directory exists, the path should be_build/<profile>/extras/test/
.The last final weird case is visible in rebar3. We have some integration suites that run only on Linux that can be called by running
rebar3 as systest ct
. The directories can be seen in:where test cases exist both in systest/ and in test/.
Common test integration is really messy, and my understanding/idea is that we should be able to take the
{dir, ...}
entries and plug them onto theout_dir(AppInfo)
result to get all the entries, plus theextras
path if it exists.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While I can see it working, I can't think of an actually nice way of doing it. I'll try giving it another thought again
This last case when it is possible to provide arbitrary directory which will contain test suites is kind of tricky to work around. My immediate solution would be just looking for
.*_SUITE.erl
files recursively in bothextras
and_build/PROFILE/lib/APP
(excludingebin
,src
,priv
andinclude
I guess).Can you spot any obvious issues with that? My concern is that I'm not sure if any not test .erl files can exist outside the aforementioned 4 directories and therefore be in danger of being affected
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, anything that specifies paths in
src_dirs
orextra_src_dirs
can contain valid Erlang files. It is configurable for each project.