Pipeline CI

VérifiéSûr

Modèles pour déboguer et étendre le pipeline CI AegisNex GitHub Actions. Couvre les modes de défaillance courants, les problèmes d'encodage, les dépendances et l'ajout de nouvelles étapes.

Spar Skills Guide Bot
DevOpsIntermédiaire
22/07/2026
Claude Code
#github-actions#ci-debugging#python#pytest#pipeline-config

Recommandé pour

Synthèse automatique

Guide de diagnostic et d'extension du pipeline GitHub Actions d'AegisNex, listant les causes de panne courantes et la manière d'ajouter de nouvelles étapes.

Points forts

  • Couvre six modes de défaillance concrets avec symptôme, cause et correctif pour chacun (BOM, dépendances manquantes, chemins Windows/Linux, timeouts, imports circulaires, mypy)
  • Fournit des extraits YAML prêts à l'emploi pour ajouter lint, vérification de types et vérification de build
  • Propose une procédure de débogage ordonnée en sept étapes, du message d'erreur à la reproduction locale sous Linux/WSL

Limites

  • Fortement spécifique au dépôt AegisNex (structure du pipeline, modules src/dashboard et src/intelligence), peu réutilisable tel quel ailleurs
  • Le document semble tronqué à la dernière étape de la procédure de débogage
  • Suppose Python 3.12 sur ubuntu-latest et ne traite pas les matrices multi-OS ou multi-versions
Quand l'utiliser

À utiliser lorsqu'un job GitHub Actions du projet AegisNex échoue ou lorsqu'il faut ajouter une étape de lint, de typage ou de vérification de build au pipeline.

Quand l'éviter

À éviter pour un pipeline CI d'un autre projet ou pour des questions générales sur GitHub Actions sans lien avec la structure et les conventions d'AegisNex.

Analyse de sécurité

Sûr
Score qualité84/100

The skill is purely documentation about debugging a GitHub Actions CI pipeline. It contains no executable commands, no curl|sh, no file deletion, no credential handling, and no obfuscated payloads. The only shell snippets are benign diagnostic examples (pytest, ruff, mypy, pip install). No declared allowed-tools further limits scope. There is no meaningful execution or exfiltration risk.

Aucun point d'attention détecté

Comment cette analyse est faite

Exemples

Diagnose a BOM parse error
The AegisNex CI run failed with `ERROR: unexpected line: '\ufeff[pytest]'`. Diagnose the root cause and tell me how to fix the file and verify it has no BOM.
Fix a ModuleNotFoundError on CI
My pull request fails in CI with `ModuleNotFoundError: No module named 'X'` but the tests pass on my machine. Walk me through the debugging steps and update requirements.txt correctly.
Add lint and type-check steps
Add a ruff lint step and a mypy type-check step to .github/workflows/pipeline.yml for the AegisNex repo, following the existing pipeline conventions.

name: ci-pipeline description: Patterns for debugging and extending the AegisNex GitHub Actions CI pipeline. Covers common failure modes, encoding issues, dependency problems, and how to add new CI steps. license: Complete terms in LICENSE.txt

CI Pipeline

You are the CI engineer for AegisNex. When a pipeline fails, you diagnose the root cause systematically rather than guessing. The pipeline lives at .github/workflows/pipeline.yml and runs on every push to main and every pull request.

Pipeline structure

The current pipeline runs on ubuntu-latest with Python 3.12:

  1. actions/checkout@v4 -- clones the repo
  2. actions/setup-python@v5 -- installs Python 3.12
  3. pip install -r requirements.txt -- installs dependencies
  4. pytest -x -vv -- runs tests, stops on first failure

Common failure modes

1. File encoding issues (BOM)

Symptom: ERROR: unexpected line: '\ufeff[pytest]' or similar parse errors on config files.

Cause: File saved with UTF-8 BOM (\xef\xbb\xbf) instead of plain UTF-8. Windows editors sometimes add BOM automatically.

Fix: Rewrite the file without BOM. Verify with:

with open("filename.ini", "rb") as f:
    raw = f.read(3)
    assert raw != b"\xef\xbb\xbf", "BOM detected"

Prevention: The repo has .editorconfig enforcing charset = utf-8 and .gitattributes with * text=auto eol=lf. Never disable these.

2. Missing dependencies

Symptom: ModuleNotFoundError: No module named X

Cause: New dependency added to code but not to requirements.txt.

Fix: Add the dependency to requirements.txt with a pinned version. Check if it has C extensions that need system packages on Ubuntu.

3. Path mismatches

Symptom: Tests find wrong files, config not loaded, import errors.

Cause: Windows paths (\) vs Linux paths (/). Hardcoded absolute paths.

Fix: Always use pathlib.Path or os.path.join(). Never hardcode paths. The CI runs on Ubuntu -- test with python -m pytest locally on Linux or WSL.

4. Timeout

Symptom: Error: Process completed with exit code 143 or job cancelled after 6 hours.

Cause: Test hangs, infinite loop, or deadlock.

Fix: Add timeout to the pytest step:

- run: pytest -x -vv
  timeout-minutes: 15

Check for unmocked network calls, blocking I/O in tests, or infinite loops in AI engine.

5. Import order / circular imports

Symptom: ImportError: cannot import name X from partially initialized module Y

Cause: Circular dependency between modules.

Fix: Move shared types to a separate module (types.py or state.py). Use TYPE_CHECKING imports for type hints. The intelligence engine uses lazy imports inside functions to avoid this -- follow that pattern.

6. Type checking failures

Symptom: mypy: error: Incompatible types in assignment

Cause: Type annotations do not match runtime usage.

Fix: Run mypy src/ locally first. Use # type: ignore[assignment] only with a comment explaining why.

How to add a new CI step

Adding a linting step

- name: Lint
  run: |
    pip install ruff
    ruff check src/

Adding a type checking step

- name: Type check
  run: |
    pip install mypy
    mypy src/ --ignore-missing-imports

Adding a build verification step

- name: Verify package
  run: |
    python -c "import src.dashboard"
    python -c "import src.intelligence.graph"

Debugging a failed CI run

  1. Read the error message carefully -- the first error is usually the root cause.
  2. Check the step that failed -- was it checkout, install, or test?
  3. Reproduce locally -- run the exact same command on Linux (WSL or Docker).
  4. Check file encoding -- if the error mentions unexpected characters, check for BOM.
  5. Check paths -- if the error is FileNotFoundError, check for Windows vs Linux paths.
  6. Check dependencies -- if ModuleNotFoundError, verify requirements.txt.
  7. Check for hanging tests -- if timeout, add --timeout=30 to pytest.

AegisNex-specific CI considerations

  • The AI engine imports are lazy (inside functions) to avoid loading LLM providers at import time. Do not change this pattern.
  • SQLite databases (ai_memory.db, aegisnex.db) are created at runtime. Tests must not depend on pre-existing databases.
  • Docker-dependent tests should be skipped in CI (@pytest.mark.skipif) unless Docker is available.
  • The frontend (Next.js) is not tested in CI yet. Only Python tests run.

Du fichier au premier essai

Le téléchargement contient exactement le contenu affiché sur cette fiche. Cette copie peut différer de la dernière version du dépôt source.

Consulter la source et ses fichiers annexes

Ce téléchargement contient uniquement SKILL.md. Les scripts, références, modèles et dépendances éventuels ne sont pas inclus. Récupérez les fichiers nécessaires depuis la source en conservant leur arborescence avant de poursuivre.

1. Télécharger le fichier

Télécharger SKILL.md

Depuis la racine d’un projet de test, enregistrez le fichier sous .skill-downloads/ci-pipeline-mrwakgc6/SKILL.md, ou utilisez la commande suivante. Ce dossier sert à examiner la skill avant son installation.

Commande pour macOS/Linux ou WSL : un shell POSIX et curl sont nécessaires. Sous Windows sans WSL, utilisez le bouton de téléchargement et créez le dossier manuellement.

mkdir -p '.skill-downloads/ci-pipeline-mrwakgc6' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/ci-pipeline-mrwakgc6/download' --output '.skill-downloads/ci-pipeline-mrwakgc6/SKILL.md.part' && mv '.skill-downloads/ci-pipeline-mrwakgc6/SKILL.md.part' '.skill-downloads/ci-pipeline-mrwakgc6/SKILL.md'

2. Vérifier les prérequis

Lisez SKILL.md avant de l’utiliser. Si le fichier cite des scripts ou services externes, examinez-les et préparez les accès nécessaires dans votre environnement de test.

Aucune section de prérequis reconnue dans ce fichier. Cela ne signifie pas qu’il est autonome : les bibliothèques, outils et accès peuvent être cités ailleurs dans le contenu ou dans le dépôt source.

Les plateformes de la fiche sont des indications du catalogue. Les chemins ci-dessous suivent la documentation des outils ; ils ne prouvent pas que cette skill y a été exécutée. Aucune version minimale de ces outils n’est attestée pour cette fiche.

3. Charger la skill

Après vérification, copiez le dossier complet dans le projet avec l’une des commandes ci-dessous, puis ouvrez une nouvelle session de l’outil. La commande s’arrête si un dossier du même nom existe déjà : comparez les fichiers avant de le remplacer.

Claude Code
test -f '.skill-downloads/ci-pipeline-mrwakgc6/SKILL.md' && test -s '.skill-downloads/ci-pipeline-mrwakgc6/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/ci-pipeline' && cp -R '.skill-downloads/ci-pipeline-mrwakgc6' '.claude/skills/ci-pipeline'

OpenSkills

OpenSkills doit déjà être installé. La procédure locale install/read est contrôlée avec OpenSkills 1.5.0, qui exige Node.js ≥ 20.6.0. Aucun slug du catalogue n’est résolu automatiquement.

Installation officielle d’OpenSkills
openskills install './.skill-downloads/ci-pipeline-mrwakgc6'

openskills read 'ci-pipeline-mrwakgc6'

La lecture doit afficher le contenu du fichier installé et son dossier de base. Elle ne lance ni la skill ni ses dépendances.

Pour un agent qui lit AGENTS.md, synchronisez ensuite l’index. Cette commande modifie AGENTS.md : relisez le diff avant de l’utiliser.

openskills sync

Mode manuel ou autre outil : joignez SKILL.md à une conversation, ou ouvrez-le dans un agent capable de lire les fichiers. Ajoutez les ressources annexes nécessaires. Il n’existe pas de dossier universel reconnu par tous les outils.

4. Faire un premier essai

Utilisez une entrée courte et fictive : un endpoint d’API, un petit document ou un brief d’interface. Dans une nouvelle conversation, joignez le fichier ou donnez son chemin à l’agent, puis adaptez cette demande :

Lis .skill-downloads/ci-pipeline-mrwakgc6/SKILL.md et applique ses instructions à cet exemple : [décrire une entrée de test]. Indique les fichiers, dépendances ou accès qui manquent. Produis le résultat demandé par la skill sans inventer de données ni exécuter de script non examiné.

Résultat attendu : une sortie correspondant aux instructions de la skill, ou une liste précise des prérequis manquants. Une simple confirmation de lecture ne valide pas le premier usage. Si une ressource externe est indisponible, ce parcours reste à tester.

Skills similaires