Summary
The Manual Integration Tests workflow (.github/workflows/manual-integration-tests.yml) is currently disabled via a fail-fast guard at the start of its job. Every recent run (this fork and upstream kubescape/storage:main) has failed on a rotating set of TestIntegrationTestSuite/Test*ProfileCreate subtests timing out at the AP-completion polling stage.
Evidence
Five consecutive runs on storage fork commit a15fb5a0 between 2026-05-15 16:32Z and 2026-05-15 17:59Z all failed with the same shape — a different *ProfileCreate variant timing out each run:
| Run |
Failing subtest |
Wall-clock at failure |
| 25929101090 |
TestJobProfileCreate |
190.13s |
| 25930235771 |
TestSidecarProfileCreate |
100.10s |
| 25930290623 |
TestSidecarProfileCreate |
100.26s |
| 25931812928 |
TestInitSidecarProfileCreate |
70.55s |
| 25932871663 |
TestCronJobProfileCreate |
270.17s |
Upstream kubescape/storage:main MIT also red (last 5 runs all failure: 20893806125, 20893315082, 20893123487, 20819593830, 16725002683).
The failover-tests (TestSimpleProfileStorageFailover, TestSimpleProfileNodeAgentFailover, TestLongStorageFailover) consistently pass.
Likely root cause
The *ProfileCreate tests use a 2-minute learning-period assumption with hard wall-clock waits. Under GitHub-runner CPU/IO contention the AP doesn't reach completion: complete inside the wait budget, and the test fails its assertion regardless of correctness. Each variant times out at a different fixed boundary, so the failures rotate across runs.
Workaround
Workflow has a fail-fast guard step at job start (see PR linking this issue). Anyone who dispatches the workflow gets an immediate failure with a pointer to this issue rather than burning ~30 minutes of CI.
Acceptance for re-enablement
Cross-references
Summary
The
Manual Integration Testsworkflow (.github/workflows/manual-integration-tests.yml) is currently disabled via a fail-fast guard at the start of its job. Every recent run (this fork and upstreamkubescape/storage:main) has failed on a rotating set ofTestIntegrationTestSuite/Test*ProfileCreatesubtests timing out at the AP-completion polling stage.Evidence
Five consecutive runs on storage fork commit
a15fb5a0between 2026-05-15 16:32Z and 2026-05-15 17:59Z all failed with the same shape — a different*ProfileCreatevariant timing out each run:Upstream
kubescape/storage:mainMIT also red (last 5 runs all failure: 20893806125, 20893315082, 20893123487, 20819593830, 16725002683).The failover-tests (
TestSimpleProfileStorageFailover,TestSimpleProfileNodeAgentFailover,TestLongStorageFailover) consistently pass.Likely root cause
The
*ProfileCreatetests use a 2-minute learning-period assumption with hard wall-clock waits. Under GitHub-runner CPU/IO contention the AP doesn't reachcompletion: completeinside the wait budget, and the test fails its assertion regardless of correctness. Each variant times out at a different fixed boundary, so the failures rotate across runs.Workaround
Workflow has a fail-fast guard step at job start (see PR linking this issue). Anyone who dispatches the workflow gets an immediate failure with a pointer to this issue rather than burning ~30 minutes of CI.
Acceptance for re-enablement
completion: completeCross-references