Build Tool Support

test-patch has the ability to support multiple build tools. Build tool plug-ins have some extra hooks to do source and object maintenance at key points. Every build tool plug-in must have one line in order to be recognized:

add_build_tool <pluginname>

Global Variables

If /(path) is used, two special substitutions may be made:

This allows for custom directories to be created and used as necessary.

The default is module.

For example, the gradle build tool does not have a standard way to execute checkstyle. So when checkstyle is requested, gradle_modules_worker sets UNSUPPORTED_TEST to true and returns out of the routine.

Required Functions

Optional Functions

Ant Specific

Command Arguments

test-patch always passes -noinput to Ant. This forces ant to be non-interactive.

Docker Mode

In Docker mode, the ${HOME}/.ivy2 directory is shared amongst all invocations.

autoconf Specific

autoconf requires make to be enabled. autoreconf is always used to rebuild the configure scripte.

Command Arguments

autoconf will always run configure with prefix set to a directory in the patch processing directory. To configure other flags, set the AUTCONF_CONF_FLAGS environment variable.

CMAKE Specific

By default, cmake will create a ‘build’ directory and perform all work there. This may be changed either on the command line or via a personality setting. cmake requires make to be enabled.

Gradle Specific

The gradle plug-in always rebuilds the gradlew file and uses gradlew as the method to execute commands.

In Docker mode, the ${HOME}/.gradle directory is shared amongst all invocations.

Make Specific

No notes.

Maven Specific

Command Arguments

test-patch always passes –batch-mode to maven to force it into non-interactive mode. Additionally, some tests will also force -fae in order to get all of messages/errors during that mode. Some tests are executed with -DskipTests. Additional arguments should be handled via the personality.

Per-instance Repositories

Under many common configurations, maven (as of 3.3.3 and lower) may not properly handle being executed by multiple processes simultaneously, especially given that some tests require the mvn install command to be used.

To assist, test-patch supports a --mvn-custom-repo option to set the -Dmaven.repo.local value to a per-instance repository directory keyed to the project and branch being used for the test. If the --jenkins flag is also passed, the instance will be tied to the Jenkins ${EXECUTOR_NUMBER} value. Otherwise, the instance value will be randomly generated via ${RANDOM}. If the repository has not been used in 30 days, it will be automatically deleted when any test run for that project (regardless of branch!).

By default, test-patch uses ${HOME}/yetus-m2 as the base directory to store these custom maven repositories. That location may be changed via the --mvn-custom-repos-dir option.

The location of the settings.xml may be changed via the --mvn-settings option.

Docker Mode

In Docker mode, ${HOME}/.m2 is shared amongst all invocations. If --mvn-custom-repos is used, all of --mvn-custom-repos-dir is shared with all invocations. The per-instance directory will be calculated and configured after Docker has launched.

Test Profile

By default, test-patch will pass -Ptest-patch to Maven. This will allow you to configure special actions that should only happen when running underneath test-patch.

Custom Maven Tests

Maven will test eclipse and site if maven is being used as the build tool and appropriate files trigger them.

Maven will trigger add a maven install test when the maven_add_install function has been used and the related tests are requierd. Plug-ins that need to run maven before MUST call it as part of their respective initialize functions, otherwise maven may fail unexpectedly. All Apache Yetus provided plug-ins that require maven will trigger the maven install functionality.