Suggestions for running tests via docker container AFTER using this action?

[tcs-cclaflin]

We use self-hosted GHA runners that have the basic docker, git, jq, yq installed. Nothing else is allowed to be installed and most build commands must be ran via a docker container. Any suggestions on how the use this action in conjunction with that requirement?

Environment details (Operating System, Cloud provider, etc): Rocky Linux running self hosted runner

What I have so far:

jobs:
  datadog-test-visibility:
    runs-on: self-hosted
    name: Configure Datadog Test Visibility
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - name: Configure Datadog Test Visibility
        uses: datadog/test-visibility-github-action@v1.0.9
        with:
          languages: java
          service: test-app-name
          api_key: ${{ secrets.DATADOG_API_KEY }}
          site: datadoghq.com
      - name: Log in to Docker Hub
        uses: docker/login-action@v3.2.0
        with:
          username: ${{ secrets.DOCKER_HUB_USERNAME }}
          password: ${{ secrets.DOCKER_HUB_PASSWORD }}
      - name: Run unit tests
        run: docker run --rm -v $(pwd):/app -w /app -e JAVA_TOOL_OPTIONS=-javaagent:/app/.datadog/dd-java-agent.jar <CUSTOM_JAVA_IMAGE> ./gradlew clean test

[nikita-tkachenko-datadog]

Hi @tcs-cclaflin! You are on the right track with your docker run command. Apart from mounting a volume with the Java agent and injecting it via the env var, you should also pass the agent config vars to the container, like this:

docker run --rm \
  -v $(pwd):/app -w /app -e JAVA_TOOL_OPTIONS=-javaagent:/app/.datadog/dd-java-agent.jar \
  $(env | grep '^DD_' | sed 's/^/-e /') \
  <CUSTOM_JAVA_IMAGE> ./gradlew clean test

[tcs-cclaflin]

@nikita-tkachenko-datadog Thank you, this got me a bit further but then I start getting errors about branch name being required and not being able to run "git log"...realized that this is due to the github agent user and docker container user not being the same and needing to run git config --global --add safe.directory /app before running ./gradlew clean test.

But now the issue is that ./gradlew clean test never finishes when JAVA_TOOL_OPTIONS is set. I'm testing everything locally in debug mode trying to find out why.

[nikita-tkachenko-datadog]

Would you be able to provide thread dumps of the Gradle daemon and the JVM that is forked for tests execution?

[tcs-cclaflin]

possibly could as a zendesk ticket but I do have it working in 2 apps now using the commands provided by the wizard rather than the env vars I got from the action:

./gradlew cleanTest test --rerun-tasks \
-Dorg.gradle.jvmargs=-javaagent:$HOME/.datadog/dd-java-agent.jar=\
dd.civisibility.enabled=true,\
dd.civisibility.agentless.enabled=true,\
dd.site=us5.datadoghq.com,\
dd.env=ci,\
dd.service=my-java-app

I'll do more testing to see if I can find the difference between using the arguments and the env vars.

[nikita-tkachenko-datadog]

The difference is that in the first case you set JAVA_TOOL_OPTIONS, which instruments every Java process, while in the second case -Dorg.gradle.jvmargs is used, which instruments only the Gradle daemon.

It is likely that the build starts some Java process (e.g. Kotlin compiler, or something similar) that gets instrumented and cannot terminate because of the injected tracer.

In order to set org.gradle.jvmargs with the env vars, the following construction can be used GRADLE_OPTS=-Dorg.gradle.jvmargs=-javaagent:....

I hope the above helps, but it'd still be nice if you could get the thread dumps, as this isn't the first time this issue is encountered, and I've been trying for a while to reproduce it, so far unsuccessfully.

[tcs-cclaflin]

Not sure exactly where that is getting configured it but I saw it in the logs and recognized that it was a path that docker wouldn't recognize so made it a path that existed in running container.

I'll see if I can get one of the java devs to help me capture a thread dump and create a zendesk ticket with them.

Thanks for the help