CI: fix CAPI pull test on windows - #4634
Conversation
|
@blotus: There are no 'kind' label on this PR. You need a 'kind' label to generate the release automatically.
DetailsI am a bot created to help the crowdsecurity developers manage community feedback and contributions. You can check out my manifest file to understand my behavior and what I can do. If you want to use this for your project, you can check out the BirthdayResearch/oss-governance-bot repository. |
|
@blotus: There are no area labels on this PR. You can add as many areas as you see fit.
DetailsI am a bot created to help the crowdsecurity developers manage community feedback and contributions. You can check out my manifest file to understand my behavior and what I can do. If you want to use this for your project, you can check out the BirthdayResearch/oss-governance-bot repository. |
|
/kind chore |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #4634 +/- ##
==========================================
- Coverage 64.62% 64.58% -0.05%
==========================================
Files 521 521
Lines 39762 39767 +5
==========================================
- Hits 25696 25682 -14
- Misses 11670 11680 +10
- Partials 2396 2405 +9
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
lgtm |
TestAPICPull/test_pull was flaky on Windows runners: the test started api.Pull() in a
goroutine, slept 500ms, then asserted the decision was in the DB, meaning that on a slow runner (windows) the write could happen after the assertion.
Test now waits for the condition (require.EventuallyWithT) instead of a fixed sleep, and
shuts down + joins the pull routine in a cleanup, so it no longer leaks a goroutine that
kept pulling against a closed DB for the rest of the package run.
apic.go: Pull()'s "waiting for scenarios" loop used a bare time.Sleep and ignored the
tomb, so the routine could not be stopped until a machine registered a scenario. It now
selects on pullTomb.Dying(). This is what made the leaked goroutine unstoppable in the
test, and it also blocks shutdown in production.