-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
[chore][cmd/otelcontribcol] Re-enable exporters and receivers tests on Windows #29532
[chore][cmd/otelcontribcol] Re-enable exporters and receivers tests on Windows #29532
Conversation
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.
Thanks @pjanotti, any idea why the tests are 4x slower on windows?
Please take a look at the failing check:
Generated code is out of date, please run "make genotelcontribcol" and commit the changes in this PR.
e741250
to
af1f1bc
Compare
I'm not sure at this point, but, I suspect the memory restrictions that are needed to run these tests on Windows GH runners: opentelemetry-collector-contrib/.github/workflows/build-and-test-windows.yml Lines 41 to 44 in 4beb5c1
I'm planning to verify that. |
I missed a required change in |
@codeboten my theory about |
The extra long duration is due to the exporters test under |
…ig on all platforms (#29553) **Description:** Discovered via #29532 (comment). The receiver configuration is not the same between Windows and the other OSes. This is not the practice for other components and make hard to write utilities dealing with the configuration on multiple platforms. The change moves some types to sources that are built for all OSes while preserving the behavior of the receiver. **Link to tracking Issue:** N/A **Testing:** Local Windows and Linux, plus CI on my fork. **Documentation:** N/A
Description:
Last part to re-enable all Windows tests disabled due to issue #11451.
Notes:
cmd
GROUP on CI and it was increased to 1200s just for this group on Windows, the default stays at 300s (which was also enough for my local run).fileexporter
life cycle test indicates an issue that shouldn't affect most usages of the collector: if the same configuration is used to export multiple signals it opens one file handle for each signal but just closes the one of them at shutdown (the helper only executes the shutdown for the one signal). This is an issue for the test because during cleanup the testing attempts to delete the test folder and there are still handles open to the file that lives inside it. This shouldn't be a problem for collector users. That said the exporter should close all file handles on shutdown. I will take look at what can be done to correct this behavior.Link to tracking Issue:
Fix #28679 - last part.
Testing:
Local run and GH CI on my fork with
Run Windows
label.Documentation:
N/A