Make CI only build/test modules with any changes#10323
Make CI only build/test modules with any changes#10323hashhar merged 9 commits intotrinodb:masterfrom
Conversation
At some point we're going to have to split product tests into modules so that only the relevant product tests run. Currently, product tests are monolithic -- if something changes in the cassandra connector, all product tests for hive, phoenix, etc will run. |
plugin/trino-hive-hadoop2/bin/run_hive_abfs_access_key_tests.sh
Outdated
Show resolved
Hide resolved
I am not sure how that would look like. Can you please elaborate @martint ? I was thinking about different approach. Currently all product tests environments configuration is known and stored in files, we could analyze that files and extract a list of features given environment is using. Like when you find a properties file with |
By making product tests a framework for building product tests (i.e., the test definitions, runners, etc. might go there), and then splitting them into separate modules, one for each connector (the specific instantiations of tests for each connector would go here). |
martint
left a comment
There was a problem hiding this comment.
[INFO] trino-benchmark [jar]
[INFO] trino-proxy [jar]
[INFO] trino-verifier [jar]
In the example above, why are those two modules being built? None of those are downstream or upstream dependencies of trino-hive-hadoop2
I believe this is because |
0c94a39 to
642facf
Compare
f90518b to
bfec977
Compare
948cdd1 to
9a0c55b
Compare
1b17879 to
f9a6f33
Compare
98a7ee7 to
d3cf3ad
Compare
There was a problem hiding this comment.
bump, let's create follow-up issues to track
pom.xml
Outdated
There was a problem hiding this comment.
Also gib.skipIfPathMatches might be helpful to ensure that change in some files (e.g. .github/workflows?) causes gib to consider all modules as impacted.
There was a problem hiding this comment.
I didn't add it because of these comments: #10323 (comment)
From the gib docs:
This property is helpful for more complex project setups in which not all submodules depend on the root module (= are not direct or indirect children of the root module).
I believe we don't have this kind of modules, right?
There was a problem hiding this comment.
No we don't have such modules as far as I can see (though nothing prevents such a module being added in future).
However in current impl we end up running GIB when github/workflows/ci.yml changes for example. And GIB says that no modules changed. We'd want the reverse behaviour for safety IMO.
There was a problem hiding this comment.
It should treat this file as part of the root module and build everything.
The gitflow-incremental-builder (GIB) Maven extension allows to only build modules that contain any changes. It compares the current git branch with the merge base and selects modules with any modified files. All (upstream) dependencies of impacted modules are built, but without running tests. All dependant (downstream) modules of impacted modules are also build and tested. If there are changes in the root module, everything would be built. Note this is only enabled in the ci profile. This does not affect product tests, which would always run with full coverage.
hashhar
left a comment
There was a problem hiding this comment.
LGTM from me.
I don't see any remaining unresolved comments so I'll merge once CI is done.
We can keep iterating as needed.
|
Thanks a lot @nineinchnick (and others who assisted and reviewed). Let's keep an eye open for any cases where we feel tests are skipped which shouldn't be and we can iterate. |
|
I messed up, the build on master failed with: I'll open up a PR to fix this ASAP |
The gitflow-incremental-builder (GIB) Maven extension allows to only build modules that contain any changes. It compares the current git branch with the merge base and selects modules with any modified files.
I enable
buildUpstreamto make sure all (upstream) dependencies are built, but without running tests. I also enablebuildDownstreamto build and test all dependant (downstream) modules. If there are changes in the root module, everything would be built.For example, when there would only be changes in the
plugin/trino-hive-hadoop2module, only the following would be built:where modules like
trino-jdbcandtrino-test-jdbc-compatibility-old-serverand dependants, so their tests would be run.Note this is only enabled in the
ciprofile and I'm adding this profile to most jobs. This does NOT affect Product Tests, which would always run with full coverage.This would probably make the separate
docsworkflow obsolete.This is a draft because I'll test different combinations of changes to be absolutely sure it won't reduce coverage.