Improve go to relevant file performance

[domingo2000]

By doing a walk over the tree of directories in the workpsace we improve the dir Glob time because it only checks for the closest test directory folder, instead of searching in all the files of the workspace.

Motivation

Closes #3327

Implementation

As discussed here the implementation consist in a tree walk over the directory structure. By doing this walk until the workspace path, we only check for test files in the most closer ancestor folder that contains tests, the locality of tests in projects using engines in rails, or Packwerck, or in general in ruby projects, make the search correct most of the times.

By checking fewer directories the performance of the Glob that search for files is improved drastically, making the go to relevant file feels instant in big projects.

Automated Tests

Changed the current test implementation to use tempdirs and create some examples in that tempdir. That way the tests are not implementation specific, as it was when stubbing the filesystem calls.

Manual Tests

1. Rubocop project

screenrecording-2025-08-30_16-11-24.mp4

2. Rails project

screenrecording-2025-08-30_16-15-06.mp4

3. Buk Core project (> 27K ruby files)

screenrecording-2025-08-30_16-14-19.mp4

[graphite-app]

How to use the Graphite Merge Queue

Add the label graphite-merge to this PR to add it to the merge queue.

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

[jenny-codes]

I like the idea but left some comments!

[domingo2000]

Thanks for the feedback @jenny-codes! I corrected all revisions, If you have any more feedback let me know.

Also checked again manually on the rubocop, rails and Buk monorepo to be sure it works well 👍🏻 .

[domingo2000]

I changed to the relative path implementation. It works fine with manual testing. I will try to change the test to use a fixture folder in the filesystem instead of stubbing the responses to test the implementation without harcoding it.

[domingo2000]

@jenny-codes I ended up testing the feature using a temporary directory strategy. That way the stubs are not implementation specific, the test is autocontained, and we don't need a real fixture folder.

[jenny-codes]

Thanks for the update! The implementation looks good but I wonder if it'd be worth it to add a test that verifies that we will search only within the "search root". We can make a test where we have this file structure

root
- a
   - test 
      - implementation_test.rb
   - implementation.rb
- b
   - test 
      - implementation_test.rb
   - implementation.rb

and assert that we don't return the implementation <> test results for a in b.

[domingo2000]

@jenny-codes, changed the test to only create the files, and added the "test within root" test to check that we don't get tests outside the search root.

[jenny-codes]

Looks good to me. Thank you!

[domingo2000]

@jenny-codes I have no permissions to merge to shopify upstream, just pinging in case you forgot, no hurry on this PR.

[jenny-codes]

@domingo2000 thank you!

[domingo2000]

Thank to you!, I really use this feature a lot, and have used a lot your initial implementation.