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
À 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.
À é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ûrThe 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 faiteExemples
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.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 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:
actions/checkout@v4-- clones the repoactions/setup-python@v5-- installs Python 3.12pip install -r requirements.txt-- installs dependenciespytest -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
- Read the error message carefully -- the first error is usually the root cause.
- Check the step that failed -- was it checkout, install, or test?
- Reproduce locally -- run the exact same command on Linux (WSL or Docker).
- Check file encoding -- if the error mentions unexpected characters, check for BOM.
- Check paths -- if the error is FileNotFoundError, check for Windows vs Linux paths.
- Check dependencies -- if ModuleNotFoundError, verify requirements.txt.
- Check for hanging tests -- if timeout, add
--timeout=30to 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 annexesCe 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.mdDepuis 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’OpenSkillsopenskills 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 syncMode 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.
Configurer un canal de discussion avec SecretRefs
DevOps
Configurez des canaux de discussion avec des commandes non interactives, les secrets étant uniquement des SecretRefs. Couvre les étapes de collecte, modification, réparation et vérification.
Enquêter sur les échecs CI de ClickHouse
DevOps
Investigue un échec CI de ClickHouse de bout en bout à partir d'une URL de PR ou de rapport S3. Récupère les tests échoués, classe flaky vs vraie régression, et cherche des issues/fixes existants.
Revue de PR Ansible
DevOps
Examine une PR Ansible selon le processus standardisé du projet, incluant la validation des changelogs, la couverture de tests et le suivi des commentaires.