question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Incremental testing on the CI

See original GitHub issue

I am considering to use GIB https://github.com/vackosar/gitflow-incremental-builder to implement the $subj.

A quick dump of things that are necessary for it to work:

No “hidden” deps

“Hidden” dependencies of Maven module M are such dependencies, that are required by the module M at build time, but they are not present in the transitive closure of M’s dependencies as seen by stock Maven.

The problem occurs e.g. in our integration tests, which explicitly depend only on runtime extension modules, but at build time, they also require their -deployment counterparts.

Hidden deps are not a problem for common sequential Maven builds, because the ordering is co-defined by the order of <module> elements in the parent-child hierarchy. However, this is an issue for parallel builds using either stock Maven or mvnd.

For mvnd, we are solving it with mvnd specific <mvnd.builder.rule>. Clearly, that’s not sufficient for GIB, that uses stock maven dependency tree builder. I learned recently, there is trick how to make hidden dependencies explicit using stock Maven model: one can use a Maven dependency with <type>pom</type>, <scope>test</scope> that excludes all its transitives via

<exclusion>
    <groupId>*</groupId>
    <artifactId>*</artifactId>
</exclusion>

It is much more XML, but would serve our needs.

Bonus: we will be able to use ‘mvn -T1C’ both on the CI and locally.

Check whether GIB handles some corner cases properly:

  • Changes of a dependency version in parent (consumed via BoM import) should trigger re-build only of the modules consuming that dependency. GIB will probably not be able to select the optimal set to re-build. If it re-builds all, it is not ideal, but at least, it will not lead to any false positive CI runs.
  • Changes of a maven plugin hosted inside the source tree should trigger re-building all modules using the plugin.

Any opnions?

Issue Analytics

  • State:open
  • Created 3 years ago
  • Comments:10 (3 by maintainers)

github_iconTop GitHub Comments

github_iconTop Results From Across the Web

What is Incremental Testing: Detailed Explanation With ...
Objective of Incremental Test · To ensure that different modules work together successfully after integration · Identify the defects earlier and ...
Read more >
What is Continuous Integration: Testing, Software & ...
Continuous Integration (CI) is a development practice where developers ... Among them are revision control, build automation and automated testing.
Read more >
Incremental Testing Tutorial: Comprehensive Guide With ...
The two types of incremental integration testing are horizontal and vertical incremental testing. What is incremental and non-incremental integration testing?
Read more >
Incremental testing: save time and money on CI for monorepo
The goal was not to eliminate all extraneous builds but to minimize the biggest offenders. And that alone made the testing much more...
Read more >
5 Ways Continuous Integration delivers Incremental ...
Enter Continuous Integration (CI) – a Software Engineering practice that aims to reduce these mishaps by enforcing build and test automation ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found