Is there a Docker image I can use for `./gradlew b...
# all-things-deployment
c
Is there a Docker image I can use for
./gradlew build
that has all necessary dependencies (Gradle, Python, etc.)?
g
There isn’t right now - the two main requirements for building are Java 8 and python 3.6+, but we also have some tests (executed during build by default, but can be skipped with
-x check
) which also require docker
c
Ok, thank you!
a
Hi @gray-shoe-75895! Follow-up: So the unit tests are always performed during
docker build
? Or is there a way to use
gradle
to run them separately? The latter would be nice for CI purposes too!
(This is specifically about the JUnit tests outside of the metadata ingestion stuff)
g
The docker build (e.g. to build linkedin/datahub-frontend) runs a gradle build for the specific component. The junit tests are largely separate - they invoke docker directly to set up dependencies for integration tests. The junit tests will automatically get invoked when running
./gradlew build
a
So
docker build
doesn't run any tests, or am I misunderstanding?
Is there any way to invoke the unit tests separately from the build step?
g
Yes the docker build doesn’t run any tests, and you should be able to run the tests using
./gradlew check
a
Hi! Thank you @gray-shoe-75895! So
./gradlew check
runs the unit tests for the frontend and gms services too? I see it running a lot of Python tests
which I would expect it to do if it was testing the metadata-ingestion code, but my main wish here is to test the other components
g
You can achieve that using -x to exclude those tests so
./gradlew check -x :metadata-ingestion:check
will run all checks except the python ones
👀 1
a
Thank you @gray-shoe-75895! That works well, except I'm getting a failure in
Execution failed for task ':metadata-io:test'
--I wonder if this is an integration test I'm supposed to disable
g
Hmm not sure about the test failure - could you post the logs from the failure? cc @big-carpet-38439
b
Hi Amanda! We've seen recently some issues with the metadata-io tests... they are quite resource intensive
We are considering disabling them on the main build
a
@big-carpet-38439 I imagine they would be, ES is a resource hog! I'm considering disabling them as well so I don't have to hassle with spinning up ES as a detached step in Drone, pointing the test at that instance, etc
b
totally agree