How to detect git changes to execute only some tests

Help
1

In a large mono repo one would probably like to not run all tests all the time.
It would be nice to detect which sub folder/project has changes (through git) and then just execute tests of these sub projects. I guess I would have a devenv.nix or flake in all sub-projects but is there already a lib/project to filter all tests by changes?

2

I may be wrong here but this seems to be more related to how that monorepo is designed, team workflow, etc…
If all projects have some test commands then repo on top can choose to call it or not

e.g:

- project-0 (root)
  - project-1
  - project-2
    - project-2-1
    - project-2-2

project-0 can have test-project-1, test-project-2, test (to test all sub-repo)

Unless configured in that way, I don’t see how changes in project-1 could affect project-2, if different repos, one won’t track the other one unless it’s asked to

3

Dependencies between project can exist but this is another topic.
A simple monorepo with projects each in its folder would be enough here.
Each has a test method. And the repo itself has a test method which calls all projects test functions.
But calling all projects test functions on a commit that only has changes in one project would be a waste.
One could do that filtering in GitHub actions etc. but I am thinking about it in Nix.
It would be something like git diff between base branch and commit branch and then detect which projects are dirty. Shurely doable. The question is… is there already a nix function or library doing something like this? I guess I am not the first thinking about this.

4

For sure, but IMO these would need be treated separately, keeping boundaries between them.

e.g if 1 repo is a REST API the other one is a client, you shouldn’t have to test the REST API when working on the client and vice-versa

If you only do unit testing, I think calling test methods in each parents repo (e.g project-0 and project-2 in the above structure example) is not necessary, trust your code and trust your tests.
If integration tests than these might be good to run on commits, so that you can check if sub-repos works together.

Depending on your git workflow, maybe only run all tests when you merge back to main / master from develop (aka before the next release).

Try to read a bit more on project architecture for mono repo, no need to re-invent the wheel here.
See how ppl manage:

  • versioning
  • releases
  • dependencies between repos
  • introducing breaking changes
  • separate concerns, boundaries
  • working with sub-repos main VS develop branch
  • etc…
    Then find the right tools for it.
5

Thx for your response!

Just to clarify, I do software development etc professionally, just not with Nix atm.
So I know about versioning, releases, dependencies etc.

There are many different ways to structure repos. I, for example would not go with sub projects.
In my case I mentioned flat projects each a folder in to root. One style ppl also use is treating library projects always as latest; meaning dependees just use the library project in the same checkout and not a versioned artifact. But I don’t want to go into dependency management here.

If you only do unit testing , I think calling test methods in each parents repo (e.g project-0 and project-2 in the above structure example) is not necessary, trust your code and trust your tests.

I don’t know how you can “trust your tests” if running them is “not necessary”.

For my taste every project change should trigger these projects tests in a PR. I am not talking about integration tests or dependencies. Just the simple tests every project has.
And since there are also many ways to organize that; just think of every PR as a release.

One repo with 100 projects and one PR to one project should not trigger tests in all projects.
The question is how to detect which tests to run/which project is dirty.

And as mentioned; yes this can be done within Github, but I was interested to do it in Nix.
Do you have any pointers how to do this detection in Nix?

6

I had assumed that each sub-project had their own git repo, my bad.

What prevents you from having a git repo for each sub-projects + the main one for root?

It is CI / CD related so IMO easier to manage that from Github.
You prolly can write some shell script to check these but again not really Nix related.

Each tool has its own prupose and use case(s), Nix here may only manages your env (aka what is needed to run your project / sub-project).
“Nixifying” everything isn’t always the solution IMHO unless there’s value to it.
Where’s the added value in your case?