Skip to content

Manual Integration Tests workflow disabled: flaky learning-period timing across all ProfileCreate variants #32

Description

@entlein

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

  • Identify which test fixture / assertion is timing-fragile
  • Replace fixed wall-clock waits with dynamic polling on AP completion: complete
  • Demonstrate 5 consecutive green runs on the same fork commit
  • Re-enable by removing the guard step

Cross-references

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions