-
Notifications
You must be signed in to change notification settings - Fork 14
Refactor container-id weblog test #4925
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
base: main
Are you sure you want to change the base?
Conversation
…y call 'cat /proc/self/cgroup' on the weblog container instead of asking the weblog application (over an HTTP call) to read a file. This allows us to instead call the '/' endpoint which all weblog applications should be handling.
…essary. They were only used for the container-id testing.
reason="Missing endpoint", | ||
) | ||
@missing_feature(context.library == "ruby" and context.weblog_variant != "rails70", reason="Missing endpoint") | ||
self.r = weblog.get("/") |
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.
Is there a reason for keeping this request ?
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.
I kept it because I thought it would be necessary in order to test that trace payloads sent to the agent have the required header. What happens if I remove it?
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.
Your test code is checking all traces trigerred by the scenario, not only this one (it's the default scenario , and there are thousand of them).
Well, it does not hurt, but as your test is no linked to only this requests, it's not that necessary. Up to you, both are fine to me.
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.
Just a small non-blocking comment/question
Motivation
We're in the process of enhancing the container-id extraction support in the C++ tracer and I wanted to update the testing to support it. The current logic depends on the weblog applications implementing a
/read_file
endpoint and the test runner trusts this endpoint, only making assertions if that value is present. This means we're showing false positives against the C++ tracer code. I'm proposing changes to make the test runner get the expected value itself, instead of getting both the expected value and the actual value from the weblog application.Changes
Refactors the container-id weblog test logic to get the expected value by directly running
cat /proc/self/cgroup
on the weblog container, instead of depending on the weblog HTTP server to self-report the cgroup via the/read_file
endpoint.This PR also removes all
/read_file
endpoints since this was the only use of the endpoint.Workflow
🚀 Once your PR is reviewed and the CI green, you can merge it!
🛟 #apm-shared-testing 🛟
Reviewer checklist
[<language>]
, double-check that only<language>
is impacted by the changebuild-XXX-image
label is present