-
Notifications
You must be signed in to change notification settings - Fork 97
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
Add a slim Docker image for testing #1630
base: main
Are you sure you want to change the base?
Conversation
970d9f7
to
3171ea9
Compare
3171ea9
to
5996f86
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have a reason to include examples/tests/licenses in the main image?
All those exclusions looks valid to me also for the main image
I guess the final image is just a thin distroless base image with the binary copied to it. No reason to copy everything there. That said, I think we do need to update our final image to contain the licenses for legal reasons. I can look into updating. |
For testing purposes we only need the auto-instrumentation code (not tests, examples, docs, etc.). Add an equivalent Dockerfile to the base one that will exclude all these extraneous items.
I plan to address this in a separate PR. The test Dockerfile is distinct enough in that it does not generate builds for non-native architectures that it cannot be unified into a single image. I plan to move forward with adding a separate test image and clean up the main build image. |
5996f86
to
8328c41
Compare
@MrAlias generating the ebpf Regardless of this, what is the motivation to generate the files outside of the container? Is it to save time in the tests? |
For testing purposes we only need the auto-instrumentation code (not tests, examples, docs, etc.). Add an equivalent Dockerfile to the base one that will exclude all these extraneous items.