Modify a file in fdb-record-layer-core#5
Open
alecgrieser wants to merge 2 commits into
Open
Conversation
alecgrieser
force-pushed
the
selective-prbs
branch
from
d46f72d to
5ffa34e
Compare
alecgrieser
force-pushed
the
modify-core-file
branch
2 times, most recently
from
7f4b7ac to
79a9a7f
Compare
alecgrieser
changed the title
fdb-record-layer-core to kick off buildfdb-record-layer-core
alecgrieser
force-pushed
the
modify-core-file
branch
2 times, most recently
from
4c86e38 to
91a9aef
Compare
alecgrieser
force-pushed
the
selective-prbs
branch
from
07f38b5 to
fa8e219
Compare
alecgrieser
force-pushed
the
modify-core-file
branch
from
91a9aef to
e36cf03
Compare
alecgrieser
force-pushed
the
modify-core-file
branch
2 times, most recently
from
4e1bd39 to
7c6c291
Compare
Change to `fdb-record-layer-core` to test: FoundationDB#4328 This should skip `fdb-extensions`, but it should run essentially all of the other tests.
alecgrieser
force-pushed
the
modify-core-file
branch
from
7c6c291 to
ceff5ba
Compare
ScottDugas
added a commit
to FoundationDB/fdb-record-layer
that referenced
this pull request
Jul 16, 2026
This adds an additional step to our PRB config. It looks at the change set, and from that, it computes a list of subprojects that have been directly affected. It combines that with a list of dependent subprojects to produce a full set of tests that need to be run. If a subproject is not affected by a change (directly or indirectly), then it gets skipped. This has a few safe-guards: 1. If a build file (as determined by the file being in the `build` or `gradle` directory or one of the top-level `gradle` files) is modified, then all of the tests get run 1. If we have errors parsing anything or determinging the changes, then we fallback to running all tests 1. This isn't perfect, but teamscale enforces that we have coverage of a function, so if there's a bug that somehow results in modified code being skipped, we should still get teamscale warnings about it 1. We continue to run all of the tests in the nightly and release jobs, so if this skips an affected module, we will still know within a day or a release, whichever is sooner 1. The plan job logs which subprojects it is running, and the coverage job notes if any subprojects were skipped The benefit, though, is that we can skip a lot of work for certain kinds of changes. For example, `fdb-extensions` has grown quite a bit with recent vector work, and this protects other PRs from needing to run that test suite. Documentation only changes can avoid testing all together (unless and until we add a documentation build, which may be a good idea), and changes to subprojects like `fdb-record-layer-lucene` or `yaml-tests` which are not dependend on by anything only need to run their own tests. Note that the list of subprojects and their downstream dependencies is now computed in `printDependentSubprojects`. This means that if a gradle change results in the dependency graph changing, those changes will be reflected automatically in picking better tests. To show how this works, I've created a few test PRs against my fork, with PRBs running only selective builds: 1. alecgrieser#4: Modifies just the README. PRB run https://github.com/alecgrieser/fdb-record-layer/actions/runs/29430521593?pr=4 validates that no tests are run (though `style` currently is) 2. alecgrieser#5: Modifies a file in `fdb-record-layer-core`. PRB run https://github.com/alecgrieser/fdb-record-layer/actions/runs/29430592325?pr=5 validates that the `fdb-extensions` tests are skipped 3. alecgrieser#6: Modifies a file in `fdb-record-layer-lucene`. PRB run https://github.com/alecgrieser/fdb-record-layer/actions/runs/29430388383?pr=6 validates that only the `fdb-record-layer-lucene` tests are run in this case 4. alecgrieser#7: Modifies some files in no known subproject. PRB run https://github.com/alecgrieser/fdb-record-layer/actions/runs/29431057921?pr=7 validates that all of the tests run with a disclaimer as to how we wound up in that state Those are the end-to-end tests. There are also unit tests of the various scenarios in `test_affected_subprojects.py`, which was run during the development process. --------- Co-authored-by: Scott Dugas <scott.dugas@gmail.com>
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Change to
fdb-record-layer-coreto test: FoundationDB#4328 This should skipfdb-extensions, but it should run essentially all of the other tests.