Gauge Java Timeout when Hosted in Corporate Cloud

[Laurie-Bamber]

Context

I'm trying to get the java-maven template working with Docker in a corporate environment in the AWS cloud. By "corporate environment" I mean we do not have access to the public internet, and pull Maven packages from an on-premises Nexus repository that we connect to via a cloud HTTP proxy server. The Gauge installation files (core executable and plugins) are installed locally via Gauge release zip files.

Problem

When I run the template in a local build or in a non-restricted cloud environment (i.e. direct access to public internet) the template executes without issue. When I run the template in our corporate cloud environment, however, Gauge keeps coming back with the below error (find the full debug log attached below):

Failed to start gauge API: Timed out connecting to java

If I set timeout parameters very high (e.g. 3000000) then after about 30 minutes Gauge will start working, although the following lines are returned before moving to execution:

exit status 1
Installed version of gauge-java (0.8.1) does not match with dependency gauge-java () specified in pom.xml file

Config/Environment

I've attached our pom.xml, settings.xml, and Dockerfile (all with sensitive content stripped) for your visibility.

Gauge: 1.4.3
Gauge-Java: 0.8.1
Java: openjdk-11
OS: alpine:3.11

Things I've Tried

• Changed Gauge versions to 1.2.1, 1.4.3, 1.5.0
• Changed gauge-maven-plugin versions
• Changed Java to versions 8, 11, 17, and gauge-java to versions 0.7.15, 0.8.1
• Changed the underlying OS to AmazonLinux2 instead of Alpine
• Increased Java heap size to minimum 2GB (via _JAVA_OPTIONS, MAVEN_OPTS, and Gauge java.properties)
• Checked proxy log and validated we are not seeing any rejected requests

settings.txt
pom.txt
Dockerfile.txt
gauge-error.log

[sriv]

Hi, do you see any .out files under your logs directory? It should contain the stdout dump from the gauge-java process.

The error is caused when gauge process is unable to connect to the runner (in this case gauge-java) process. I am not sure why this behaviour would happen when a proxy is used, it does sound odd.

after about 30 minutes Gauge will start working

This is not at all how it should be.

[Laurie-Bamber]

Hey @sriv thanks for picking this up - I've attached the log files below for the latest run. Unfortunately the java log only includes lines which occurred after the 30-minute wait for gauge-java to be loaded.

80-java.out.log
gauge (4).log

[Laurie-Bamber]

Interestingly the timeout period for each run seems to be 30m:40s (with a minor deviation of around 2s) before returning exit status 1 - could it be this line in the gauge-java code where this error originates? I can't see any log statements before this point except for the END line where the timeout begins.

[Laurie-Bamber]

Hi all, I've now identified what was causing this issue.

Our settings.xml is located in the working directory of our maven project instead of in the default .m2 location. Previously this hasn't been an issue as we manually specify mvn -s ./settings.xml, however within the gauge-java code there is a line which runs mvn dependency:tree without passing in the above settings reference, so this command is running without awareness of our proxy server or the local repository where all our plugins/packages are stored.

I believe in this situation it attempts to redownload all packages from central, and timeouts for each individual plugin/dependency. This would explain why we're not seeing logs for this in our proxy (as traffic never reaches the proxy in the first place), and why the local build and other cloud build are working (as they're run in less restrictive networking environments so they can reach central in this situation).

[reka18]

I literally have been encountering this issue while trying to run gauge in Github Actions

[Laurie-Bamber]

@reka18 The bit of code only runs when it detects a pom.xml file in your project root - a temporary workaround is to change the name of this file then refer to it directly when running mvn gauge:execute, and your tests should skip the function which causes the timeout. Or just add the settings.xml to the default directory of course!