Feat: Special Monitoring for Scalability Tests

[knabben]

Description

The handbook identifies scalability tests as a special high-risk test category that requires monitoring. Currently, signalhound does not have special handling for scalability tests.

The following scalability jobs/tests could regress quite easily (due to seemingly unrelated PRs anywhere in the k8s codebase) and require constant manual monitoring/triaging and domain expertise to investigate and resolve.

master-blocking gce-cos-master-scalability-100
master-informing gce-scale-correctness
master-informing gce-scale-performance
release-x.y-blocking gce-cos-x.y-scalability-100

Requirements

• Identify scalability tests from test names or categories
• Apply special monitoring rules for scalability tests
• Highlight scalability test failures in reports
• Support scalability test-specific thresholds

Acceptance Criteria

• Scalability tests are identified
• Special monitoring is applied to scalability tests
• Scalability test failures are highlighted in reports
• Configurable thresholds for scalability tests
• Unit tests for scalability test detection
• Integration tests with scalability test data

Implementation Notes

• Detect scalability tests from test names (e.g., "scale", "load", "performance")
• Apply higher priority or special handling
• Add scalability test category to reports

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten