Recompile material in test-images.tar.gz in Grinder

[fengxue-IS]

Currently Grinder consumes the pre-compiled test resource from JDK build's test-images.tar.gz, if a test change is made to on of the compiled libs, it would require developer to rebuild a custom JDK so Grinder would be able to pick up the change.

It would be much simpler if Grinder job can have a option to recompile the test libs without need to recompile entire JDK

[llxia]

It looks like we can run test-image: https://github.com/ibmruntimes/openj9-openjdk-jdk11/blob/95a3a61b3bbd5ed37e4f840c8f6552cace79c462/doc/building.md?plain=1#L781 https://github.com/ibmruntimes/openj9-openjdk-jdk11/blob/95a3a61b3bbd5ed37e4f840c8f6552cace79c462/make/Main.gmk#L948 internal diff

def get_compile_command() {
    def make_target = ''
    if ((SDK_VERSION == "17") && SPEC.contains('zos')) {
         make_target = 'images test-image debug-image'
    } else if ((SDK_VERSION == "21") && SPEC.contains('zos')) {
         make_target = 'images debug-image'
    } else {
         make_target = 'all'
    }
    return "make ${EXTRA_MAKE_OPTIONS} ${make_target}"
}

openj9 image: https://github.com/ibmruntimes/openj9-openjdk-jdk11/blob/95a3a61b3bbd5ed37e4f840c8f6552cace79c462/closed/custom/Main.gmk#L33

[pshipton]

To make the test-image it first needs to build the JVM, so basically it will be doing an entire build. Maybe saving a little time by not building all but the bulk of the time is to build the JVM. I expect re-building the test-image should be left to the user to manage. The most efficient way is to have manual build setup where you change the code and then build again, which will do an incremental build, only recompiling the pieces that changed.

[pshipton]

Also a factor is that not all test machines are suitable for running builds. A JDK/test image build needs to run on a build machine.