The Atlassian Community Forums are currently in read-only mode. We will be relaunching on a new platform on September 22 (read more here). We apologize for the extended downtime. For concerns or questions, please email communitymanagers@atlassian.com. See you on the other side, on the new Atlassian Community Forums! :)

×

Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

test-results are not created

Alex Philippi
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
April 10, 2019

Hi,

we are using the image atlassian/default-image:2 for our pipeline and we trigger ./gradlew test to run our unit tests. The tests are getting executed, but if the gradle task test is runs inside the image no test-reports are created.

We are using the standard gradle test task with enabled xml creation: test { reports { junitXml.enabled = true } } (gradle 5.3.1)

If I run ./gradlew test locally, the test-results and -reports folder are created. The image only creates the folders classes, generated, libs and tmp in the build folder.

Does anyone has an idea why this is working locally but not within the image? Should I switch to another image?

Best Regards

Alex

1 answer

Comments for this post are closed

Community moderators have prevented the ability to post new answers.

0 votes
Tom Bradshaw
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
April 15, 2019

Hi @Alex Philippi,

It's possible that you don't need to add the junitXml.enabled = true line. Under the gradle heading of the documentation at https://confluence.atlassian.com/bitbucket/test-reporting-in-pipelines-939708543.html it says that gradle will emit test results in the expected format by default.

If removing this line doesn't work there are a few things you can try.

The first thing is to try to debug this locally but within a docker image (https://confluence.atlassian.com/bitbucket/debug-your-pipelines-locally-with-docker-838273569.html). This will help eliminate possible problems caused by running the build in a container. 

The second thing is add commands to the end of your build that will check whether the files are actually being created. My suggestion is to using the `ls` command on the test output folder to check that it is populated and then using the `cat` command to obtain the contents from those files to check that it is the same as the local versions.

Cheers,

Tom

TAGS
AUG Leaders

Atlassian Community Events