HyperShift E2E Test Runner

Cette skill permet une itération autonome sur les tests e2e - exécution des tests, analyse des défaillances, corrections et ré-exécution jusqu'à la réussite.

Quand utiliser cette skill

Cette skill s'applique automatiquement quand :

Vous implémentez une feature qui nécessite une validation de test e2e
Vous corrigez un test e2e défaillant
Vous travaillez sur une tâche où l'utilisateur veut que vous itériez jusqu'à la réussite des tests
Vous déboguez des défaillances de tests dans le répertoire test/e2e/
L'utilisateur mentionne l'exécution de tests e2e ou la validation de changements contre un cluster en direct

Prérequis

Sourcer le fichier d'environnement avant d'utiliser cette skill :

source dev/claude-env.sh

Configuration de l'environnement

Variables d'environnement de dev/claude-env.sh :

Variable	Description
`E2E_PLATFORM`	Plateforme de test (AWS, Azure, etc.)
`AWS_CREDENTIALS`	Chemin vers le fichier des identifiants AWS
`OIDC_BUCKET`	Bucket S3 pour OIDC
`BASE_DOMAIN`	Domaine DNS de base
`PULL_SECRET`	Chemin vers le fichier de secret pull
`AWS_REGION`	Région AWS
`E2E_ARTIFACT_DIR`	Répertoire pour les artifacts de test
`MGMT_KUBECONFIG`	Chemin vers le kubeconfig du cluster de gestion
`CPO_IMAGE_REPO`	Dépôt d'image CPO personnalisé
`RUNTIME`	Runtime de conteneur (podman/docker)

Exécution des tests E2E

Étape 1 : Vérifier si le binaire de test doit être reconstruit

CRITIQUE : Avant d'exécuter tout test e2e, vous DEVEZ vérifier si le binaire de test doit être reconstruit :

# Vérifier si le binaire existe
if [ ! -f ./bin/test-e2e ]; then
  echo "Test binary missing, building..."
  make e2e
fi

# Vérifier si des fichiers de test sont plus récents que le binaire
NEWEST_TEST=$(find test/e2e -name "*.go" -newer ./bin/test-e2e 2>/dev/null | head -1)
if [ -n "$NEWEST_TEST" ]; then
  echo "Test files changed (e.g., $NEWEST_TEST), rebuilding..."
  make e2e
fi

Étape 2 : Exécuter le test

Construire et exécuter la commande de test :

KUBECONFIG=$MGMT_KUBECONFIG \
./bin/test-e2e -test.v -test.timeout 2h \
  -test.run "TEST_PATTERN" \
  -test.v \
  --e2e.platform $E2E_PLATFORM \
  --e2e.aws-credentials-file $AWS_CREDENTIALS \
  --e2e.aws-oidc-s3-bucket-name $OIDC_BUCKET \
  --e2e.base-domain $BASE_DOMAIN \
  --e2e.pull-secret-file $PULL_SECRET \
  --e2e.aws-region $AWS_REGION \
  --e2e.artifact-dir $E2E_ARTIFACT_DIR

Étape 3 : Ajouter une image CPO personnalisée (En cas de modifications du control plane)

Si vous avez apporté des modifications au code du control-plane-operator et créé une image personnalisée, ajoutez :

-e2e.control-plane-operator-image $CPO_IMAGE_REPO:TAG

Boucle d'itération

Quand vous travaillez en mode autonome sur une tâche qui nécessite une validation e2e :

1. Exécution initiale du test

Exécuter le test pour établir une baseline :

KUBECONFIG=$MGMT_KUBECONFIG ./bin/test-e2e -test.v -test.run "TestName" [flags...]

2. En cas d'échec - Analyser

Lire attentivement la sortie du test
Vérifier les artifacts dans le répertoire $E2E_ARTIFACT_DIR/ pour :
- Les logs des pods
- Les événements
- Les états des ressources
Identifier la cause racine

3. Apporter des corrections

Éditer le code pertinent (code de test, code d'opérateur, etc.)
Si vous avez modifié des fichiers test/e2e/*.go, le binaire sera reconstruit automatiquement à la prochaine exécution

4. Reconstruire les images (si nécessaire)

Si vous avez modifié le code du control-plane-operator : Utiliser la skill build-cpo-image pour construire et pousser une nouvelle image.

$RUNTIME build -f Dockerfile.control-plane --platform linux/amd64 -t $CPO_IMAGE_REPO:NEW_TAG .
$RUNTIME push $CPO_IMAGE_REPO:NEW_TAG

5. Ré-exécuter le test

Exécuter le test à nouveau avec le code/les images mis à jour. Répéter jusqu'à la réussite.

Motifs de test courants

Motif de test	Description
`TestNodePool`	Tous les tests NodePool
`TestNodePool/HostedCluster0/Main/TestSpotTerminationHandler`	Test spot spécifique
`TestNodePool.*Karpenter`	Tous les tests liés à Karpenter
`TestCreateCluster`	Tests de création de cluster
`TestUpgrade`	Tests de mise à jour

Analyse des défaillances de test

Vérifier la sortie du test

La sortie du test inclut :

Nom du test et statut
Défaillances d'assertion avec comparaison attendu vs réel
Informations de timeout
Logs de création/suppression de ressources

Vérifier le répertoire d'artifacts

Après une défaillance de test, examiner :

ls -la $E2E_ARTIFACT_DIR/
# Contient : manifests du cluster, logs des pods, événements, dumps de ressources

Motifs de défaillance courants

Motif	Cause probable
`context deadline exceeded`	La ressource n'a pas atteint l'état attendu à temps
`not found`	La ressource n'a pas été créée ou a été supprimée prématurément
`connection refused`	Service non prêt ou problème réseau
`forbidden`	Problème RBAC ou de permission

Construire le binaire de test

Quand le code de test change, reconstruire :

make e2e

Ceci compile ./bin/test-e2e avec tous les tests de test/e2e/.

Notes

Les tests prennent généralement 10-30+ minutes selon la complexité
Certains tests créent de vraies ressources AWS (coûtent de l'argent, nécessitent un nettoyage en cas d'échec)
Utiliser -test.timeout pour définir des timeouts appropriés (défaut : 2h)
Le répertoire d'artifacts est écrasé à chaque exécution
Pour les tests longs, considérer l'exécution en arrière-plan et la vérification périodique