Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mps-test doesn't include ingestion-sink JAR #716

Open
ahounsel opened this issue Jan 21, 2022 · 2 comments
Open

mps-test doesn't include ingestion-sink JAR #716

ahounsel opened this issue Jan 21, 2022 · 2 comments

Comments

@ahounsel
Copy link
Contributor

ahounsel commented Jan 21, 2022

I'm trying to update the schema for a custom ping that we developed for a Normandy study (telemetry/dnssec-study-v1). I want to test my changes and ensure that they're not breaking the schema. However, I'm having trouble getting the tests to run in Docker.

I'm on a 2018 Macbook Pro running Catalina. When I run mps-build followed by mps-test, the tests hang on "Collecting 0 items." To investigate further, I modified mps-test to replace --entrypoint=pytest with --entrypoint=/bin/bash. This shelled me into a container, so I then ran pytest -s -v to see if any errors would get printed. This seems to be the problem causing the tests to hang:

jnius.JavaException: JVM exception occurred: com/mozilla/telemetry/ingestion/sink/config/SinkConfig java.lang.NoClassDefFoundError

Interestingly, if I simply remove the --volume "$(pwd)":/app flag from mps-test, the dependency seems to appear in the container in target/ingestion-sink-0.1-SNAPSHOT.jar and target/ingestion-sink-0.1-SNAPSHOT.lib. When I run pytest -s -v again, the tests work.

Anyone have insight into why the ingestion-sink JAR is not copied over to the container when I run mps-test?

@jklukas
Copy link
Contributor

jklukas commented Jan 21, 2022

The Dockerfile includes RUN mvn dependency:copy-dependencies which is how target/ingestion-sink-0.1-SNAPSHOT.jar ends up in the built image at /app/target/ingestion-sink-0.1-SNAPSHOT.jar. In the mps-test script, I see now there a comment:

# NOTE: this will shadow java dependencies in `target/dependency`

So your steps to repro I think make sense to me. The --volume "$(pwd)":/app flag mounts the contents our your current directory at /app so the target/ directory becomes inaccessible.

The point of --volume "$(pwd)":/app is that you're able to rerun tests without having to rebuild the container. By taking that line out, you'll need to rebuild the image every time you make a change in the templates dir in order to have those changes reflected when you run the test.

I'm thinking about potential workarounds here.

jklukas added a commit that referenced this issue Jan 21, 2022
jklukas added a commit that referenced this issue Jan 21, 2022
@jklukas
Copy link
Contributor

jklukas commented Jan 21, 2022

Thanks for writing this up, @ahounsel!

jklukas added a commit that referenced this issue Jan 25, 2022
* Don't mount entire pwd in mps-tests

Should address #716

* Force x86
bytesized pushed a commit to bytesized/mozilla-pipeline-schemas that referenced this issue Aug 23, 2022
* Don't mount entire pwd in mps-tests

Should address mozilla-services#716

* Force x86
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants