Allow plugin reader to ignore dependents of plugins#12854
Allow plugin reader to ignore dependents of plugins#12854nineinchnick wants to merge 3 commits intotrinodb:masterfrom
Conversation
|
Can you give an example scenario that this would improve? Something like "a PR that touches a file in X would previous do Y but now does Z" |
@electrum let me try:
WDYT? We should generally ignore all dependents of plugins but I don't want to pull in Maven code into the Plugin reader and I don't think there's a high chance of any other module than |
We plan to squash the hive-hadoop2 plugin into the main Hive module. There’s no need at this point for a separate module. At that point, Iceberg and Delta plugins will depend on the Hive plugin. |
4fabc4c to
cb9f80b
Compare
cb9f80b to
095d285
Compare
095d285 to
7590818
Compare
If the server and/or rpm modules are impacted, the list list of impacted modules should not be empty, because otherwise it will cause all tests to run.
7590818 to
60fdd2f
Compare
|
I tested this in nineinchnick#14 |
@nineinchnick thanks! still, i'd prefer someone else reviews this. I have no prior experience with the plugin reader and surrounding functionalities. |
hashhar
left a comment
There was a problem hiding this comment.
making sure i understand things correctly
| Stream<Map.Entry<String, String>> modulesStream = requireNonNull(modulesToPlugins).entrySet().stream(); | ||
| if (impactedModules.isPresent()) { | ||
| List<String> nonPluginModules = impactedModules.get().stream().filter(module -> !modulesToPlugins.containsKey(module)).collect(Collectors.toList()); | ||
| List<String> nonPluginModules = impactedModules.get().stream() |
There was a problem hiding this comment.
Probably best to rename this variable since it's no longer just nonPluginModules.
There was a problem hiding this comment.
Also add context to commit message of " Allow plugin reader to ignore dependents of plugins "
IIUC this means we now apply impact analysis in product tests if change is in core/trino-server or core/trino-server-rpm whereas earlier we'd have just run all tests.
There was a problem hiding this comment.
That brings up concern - what happens when in future some plugin module gets used as dependency in other plugin module?
It might not be as concerning since the only impact would be we'd run more product tests than needed?
| run: | | ||
| export MAVEN_OPTS="${MAVEN_INSTALL_OPTS}" | ||
| $MAVEN validate ${MAVEN_FAST_INSTALL} ${MAVEN_GIB} -Dgib.logImpactedTo=gib-impacted.log -pl '!:trino-docs,!:trino-server-rpm' | ||
| $MAVEN validate ${MAVEN_FAST_INSTALL} ${MAVEN_GIB} -Dgib.logImpactedTo=gib-impacted.log -pl '!:trino-docs' |
There was a problem hiding this comment.
the list list in commit message for "Don't exclude server modules when checking impacted modules"
| - name: Build PT matrix (all) | ||
| if: | | ||
| github.event.name != 'pull_request' || | ||
| github.event_name != 'pull_request' || |
There was a problem hiding this comment.
this was extracted - remove this commit?
|
I closed this because after giving it another thought I don't think we should be doing impact analysis when we know that some dependants of plugins have changed. |
Description
When the plugin reader is used to map impacted plugins to features, it should not ignore the whole list when the dependents of plugins are included. In Trino that can only be
core/trino-serverbut it currently doesn't define dependencies explicitly, because it would duplicate its Provisio manifest.Related issues, pull requests, and links
Documentation
(x) No documentation is needed.
( ) Sufficient documentation is included in this PR.
( ) Documentation PR is available with #prnumber.
( ) Documentation issue #issuenumber is filed, and can be handled later.
Release notes
(x) No release notes entries required.
( ) Release notes entries required with the following suggested text: