Skip to content

Modification to readme to test selective PRB#4

Open
alecgrieser wants to merge 1 commit into
selective-prbsfrom
modify-readme
Open

Modification to readme to test selective PRB#4
alecgrieser wants to merge 1 commit into
selective-prbsfrom
modify-readme

Conversation

@alecgrieser

Copy link
Copy Markdown
Owner

Test for FoundationDB#4328: try editing just the readme and see what jobs get selected.

Should be: none

@alecgrieser alecgrieser force-pushed the modify-readme branch 2 times, most recently from 1b3db6d to 02c5727 Compare July 9, 2026 13:57
@alecgrieser alecgrieser added the enhancement New feature or request label Jul 9, 2026
@alecgrieser alecgrieser force-pushed the modify-readme branch 2 times, most recently from 9348c38 to a2d9b6b Compare July 9, 2026 17:58
@alecgrieser alecgrieser force-pushed the modify-readme branch 2 times, most recently from e8f4cad to f017e54 Compare July 15, 2026 15:55
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant