For example, I would like for a PR to workflow-cps to automatically run tests in other plugins, like workflow-cps-global-lib, with the workflow-cps dependency set to the locally built snapshot. Now for simple cases this could be done easily already with no tricks: ensure that the workflow-cps-global-lib POM defines a workflow-cps-plugin.version property, and override that (as well as jenkins.version where necessary). The trouble comes when the PR to workflow-cps is downstream of a PR to, say, workflow-api. Presumably workflow-cps-global-lib is still using an older (release) version of workflow-api, so the integration test will fail. You could make it define a workflow-api-plugin.version property too, but this could become an endless exercise in replacing every dependency version with a property, and anyway the Jenkinsfile for the workflow-cps PR would then need to be patched to explicitly request the new (timestamped!) snapshot version of workflow-api, duplicating information in pom.xml. This seems unmaintainable. I would rather run the integration test Maven build with some special option, or with some special preprocessing, that automatically updates the workflow-cps version and any transitive dependencies (ideally including the Jenkins baseline too—currently workflow-cps in fact uses a newer baseline than workflow-cps-global-lib) to the upper bounds.