| name | qa-tester |
| description | Testing funcional y de integración de GitHooks como QA tester. Prueba todos los comandos CLI (flow, job, hook, conf:check, conf:migrate, cache:clear, status, system:info, tool), edge cases de configuración, formatos de salida, flags, combinaciones y compatibilidad legacy. Usa esta skill cuando el usuario quiera probar, verificar, o validar funcionalidades del CLI, buscar bugs, hacer testing de aceptación, o cuando mencione "probar", "testear funcionalidad", "verificar comando", "QA", "edge cases", "testing funcional".
|
QA Testing funcional de GitHooks
Guía para hacer testing funcional exhaustivo del CLI de GitHooks.
Principios de testing
-
Probar como un QA tester hostil: no verificar que los ficheros existen, EJECUTAR los comandos y comprobar el resultado real.
-
Probar edge cases: inputs vacíos, tipos incorrectos, valores límite, combinaciones imposibles.
-
Probar en entorno real: usar /var/www/html3 como proyecto de prueba — es un proyecto Composer real con tools instaladas, ficheros con errores a propósito y configs variadas.
-
No asumir que funciona: si el Changelog dice que una feature existe, PROBARLA.
-
El CWD importa: la auto-detección de executablePath busca vendor/bin/ relativo al directorio actual. Ejecutar desde /var/www/html3 (tiene vendor/bin/) vs otro directorio da resultados diferentes.
-
Leer la implementación antes de crear configs de test: ante cualquier output inesperado (warnings, errores), buscar en src/ el mensaje exacto con Grep para entender de dónde viene antes de catalogar como BUG.
-
Medir el exit code SIN pipe. Después de un pipe, $? es el exit code del último comando del pipeline (head, tail, python3…), no del binario que pruebas. Eso ha provocado falsos positivos masivos en sesiones reales (todo un bloque de 18 "BUGs" de exit 0 que en realidad eran exit 1). Patrón correcto:
php7.4 vendor/bin/githooks conf:check --config=X.php > /dev/null 2>&1
echo "EXIT: $?"
php7.4 vendor/bin/githooks conf:check --config=X.php 2>&1 | head -20; echo "EXIT=$?"
Si necesitas ver el output y el exit code en el mismo bloque, vuelca el output a fichero antes:
php7.4 vendor/bin/githooks conf:check --config=X.php > /tmp/qa-out 2>&1
echo "EXIT: $?"
head -20 /tmp/qa-out
Variantes válidas en zsh para preservar exit del primer comando del pipeline: ${pipestatus[1]}. En bash: ${PIPESTATUS[0]}.
Antes de catalogar un caso como "exit 0 cuando se esperaba 1", repite la medición sin pipe. Una herramienta verificadora externa lo descubrirá en segundos y desmontará el reporte.
Pre-flight: allowlist de permisos
La skill cruza la barrera entre html1 (proyecto raíz) y html3 (proyecto de prueba). Sin un allowlist específico, cada Read/Write en html3 y cada rm -rf reports/v33-* dispara un prompt de permiso que rompe el ritmo del testing.
Antes de empezar, comprobar que /var/www/html1/.claude/settings.local.json (el del proyecto activo cuando se invoca la skill) incluye estos permisos. Si falta alguno, añadirlo:
"Read(//var/www/html3/**)",
"Edit(//var/www/html3/**)",
"Write(//var/www/html3/**)",
"Write(//tmp/v33-*)",
"Write(//tmp/qa-*)",
"Bash(rm -rf reports/v33-*)",
"Bash(rm -rf /tmp/v33-*)",
"Bash(md5sum:*)",
"Bash(seq:*)",
"Bash(cd /var/www/html3*)"
Read(//var/www/html3/**) evita 3-5 prompts por sesión leyendo configs y TESTS-vX.Y.md. Write(//tmp/v33-*) cubre los configs inline de tests "(editar inline)" sin tener que checked-in cada uno. Bash(rm -rf reports/v33-*) y Bash(rm -rf /tmp/v33-*) cubren la limpieza entre bloques.
Paso 0: Preguntar al usuario
Antes de empezar, preguntar:
- Versión a probar:
2.x o 3.x (ej: 3.0.0)
- Versión de PHP:
7.4, 8.0, 8.1, 8.2, 8.3, 8.4, 8.5...
- Build: ¿Usar la build actual o construir una nueva?
Con estos datos se determina:
| Dato | Valor |
|---|
| Rama RC en html1 | rc-{versión} (ej: rc-3.0.0) |
| Rama en html3 | master para 3.x, 2.x para 2.x |
| Versión Composer | dev-rc-{versión} (ej: dev-rc-3.0.0) |
| Binario | vendor/bin/githooks (instalado por Composer) |
| Abreviatura en tests | GH = phpX.Y vendor/bin/githooks |
| Post-update necesario | Sí si PHP < 8.1, No si PHP >= 8.1 |
Gestión de la build
Los binarios se encuentran en:
builds/githooks — para PHP 8.1+builds/php7.4/githooks — para PHP 7.4, 8.0
Verificar si la build existe y está actualizada:
ls -la builds/githooks builds/php7.4/githooks
git log --oneline -1 -- builds/
git log --oneline -1
Si la build no existe o está desactualizada respecto al código, preguntar al usuario:
Los builds están desactualizados (código más reciente que la build). ¿Quieres que construya una build nueva antes de probar?
Si el usuario quiere build nueva, construir con la versión de PHP del tier correspondiente:
| PHP para tests | PHP para build | Comando |
|---|
| 7.4, 8.0 | php7.4 | php7.4 githooks app:pre-build php && php7.4 githooks app:build |
| 8.1, 8.2, 8.3, 8.4, 8.5 | php8.1 | php8.1 githooks app:pre-build php && php8.1 githooks app:build |
Importante: el build elimina las dev dependencies de html1. Tras el build, restaurarlas:
git checkout -- composer.json && php{X.Y} tools/composer update
Si el usuario quiere usar la build actual, verificar que los binarios existen. Si no existen, avisar y preguntar de nuevo.
Paso 1: Preparar el entorno de pruebas
cd /var/www/html3
git checkout {master|2.x}
git checkout -b {version}-prueba
cp composer.example.json composer.json
Editar composer.json
Reemplazar la versión de githooks:
php{X.Y} -r '
$json = json_decode(file_get_contents("composer.json"), true);
$json["require-dev"]["wtyd/githooks"] = "dev-rc-{versión}";
file_put_contents("composer.json", json_encode($json, JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES) . "\n");
'
Si PHP < 8.1, añadir el evento post-update-cmd para instalar el binario correcto:
php{X.Y} -r '
$json = json_decode(file_get_contents("composer.json"), true);
$json["scripts"] = [
"post-update-cmd" => ["Wtyd\\GitHooks\\Utils\\ComposerUpdater::phpOldVersions"]
];
file_put_contents("composer.json", json_encode($json, JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES) . "\n");
'
Recordatorio — Cuándo es necesario post-update-cmd:
| Composer update con | Ejecutable con | Tier | Post-update |
|---|
| php7.4 | PHP 7.4, 8.0 | builds/php7.4/ | Sí |
| php8.1+ | PHP 8.1, 8.2, 8.3, 8.4, 8.5 | builds/ | No |
Sin el post-update-cmd en PHP <8.1, vendor/bin/githooks apuntará al build de 8.1+ que no es compatible.
Instalar dependencias
php{X.Y} composer.phar update
Esto instala GitHooks desde Packagist (rama RC) con el binario correcto en vendor/bin/githooks.
Verificar instalación
php{X.Y} vendor/bin/githooks --version
Debe mostrar la versión correspondiente sin errores PHP.
Paso 2: Ejecutar los tests
Consultar TESTS.md en la rama actual de html3. Contiene el catálogo completo de tests con comandos exactos, salidas esperadas, exit codes y SHAs de commit para cada test.
Patrón de ejecución
Todos los tests se ejecutan DESDE /var/www/html3:
cd /var/www/html3
php{X.Y} vendor/bin/githooks <comando> [--config=<config>]
Sin --config, busca githooks.php en el CWD.
Ir al commit correcto (si el test lo indica)
Algunos tests requieren un SHA específico. Antes de ejecutar:
git checkout <SHA>
Tras el test, volver a la rama de prueba:
git checkout {version}-prueba
Entorno de pruebas: /var/www/html3
Estructura
/var/www/html3/
├── composer.example.json # Template — copiar a composer.json y editar
├── composer.phar # Composer standalone (no depende del sistema)
├── src/
│ ├── CleanFile.php # Código limpio — pasa todas las tools
│ ├── FileWithErrors.php # Variable no usada, propiedad undefined — falla phpstan, phpmd
│ ├── SyntaxError.php # Syntax error PHP — falla parallel-lint
│ ├── DuplicateA.php # Código duplicado con DuplicateB — falla phpcpd
│ └── DuplicateB.php # (mismo código que DuplicateA)
├── tests/
│ ├── PassingTest.php # assertTrue(true) — pasa phpunit
│ └── FailingTest.php # assertTrue(false) — falla phpunit
├── phpunit.xml # Config PHPUnit (testsuite "default" → tests/)
├── psalm.xml # Config Psalm (errorLevel 8, src/)
├── TESTS.md # Catálogo completo de tests con SHAs
└── [configs por rama] # githooks.php, githooks-v3.php, etc.
Tools disponibles vs no disponibles
| Tool | Binario en vendor/bin/ | Notas |
|---|
| phpstan | Sí | Falla con FileWithErrors.php |
| phpcs / phpcbf | Sí | Falla con FileWithErrors.php (PSR12) |
| phpmd | Sí | Falla con FileWithErrors.php (unusedcode) |
| parallel-lint | Sí | Falla con SyntaxError.php |
| phpunit | No | phpunit.xml existe pero no hay binario — probar que el error es descriptivo |
| psalm | No | psalm.xml existe pero no hay binario — probar que el error es descriptivo |
| phpcpd | No | DuplicateA/B.php preparados para cuando se instale |
Errores esperados por fichero
| Fichero | parallel-lint | phpcs | phpmd | phpstan |
|---|
CleanFile.php | OK | OK | OK | OK |
FileWithErrors.php | OK | KO (PSR12) | KO (unusedcode) | KO (undefined property) |
SyntaxError.php | KO (syntax) | KO | KO | KO |
DuplicateA/B.php | OK | OK | OK | OK |
Configs de test adicionales
Cuando necesites una config v3 o una config rota que no exista ya, créalas en /var/www/html3/ con nombre descriptivo.
IMPORTANTE: antes de crear una config, leer la implementación en src/ para entender el formato exacto. Las condiciones de ejecución condicional (only-on, exclude-on, only-files, exclude-files) van en la sección hooks como parte del HookRef, NO en options del flow. Ejemplo:
'hooks' => [
'pre-commit' => [
['flow' => 'qa', 'only-on' => ['main', 'release/*']],
['job' => 'audit', 'only-files' => ['src/**/*.php']],
],
],
Áreas de testing
1. Comandos básicos — Happy path
| Comando | Qué probar | Comando exacto |
|---|
flow <name> | Flow existente | GH flow qa --config=githooks-v3.php |
flow <name> | Flow inexistente | ... flow inventado --config=githooks-v3.php → error + lista de flows |
job <name> | Job existente | ... job parallel_lint --config=githooks-v3.php |
job <name> | Job inexistente | ... job inventado --config=githooks-v3.php → error + lista de jobs |
conf:check | Config válida v3 | ... conf:check --config=githooks-v3.php → tabla con Status |
conf:check | Config legacy | ... conf:check (usa githooks.php v2) → tablas + warning migración |
conf:migrate | Desde v2 a v3 | Copiar githooks.php a tmp, migrar, verificar backup + formato nuevo |
status | Con y sin hooks | Instalar hooks, verificar synced; limpiar, verificar missing |
system:info | Info del sistema | ... system:info → CPUs, processes |
cache:clear | Sin cachés | ... cache:clear --config=githooks-v3.php → reporta "not found" |
cache:clear | Con cachés | Crear .phpcs.cache, ejecutar, verificar borrado |
cache:clear | Por flow | ... cache:clear qa --config=githooks-v3.php → borra cachés de todos los jobs del flow |
tool (legacy) | Deprecation warning | ... tool all full → warning de deprecación |
2. Edge cases de configuración
Crear ficheros PHP en /var/www/html3/ con la config de prueba.
| Caso | Config | Resultado esperado |
|---|
| Config vacía | return []; | Error o warning: jobs missing |
| Sin sección flows | Solo jobs y hooks | Funciona si hooks referencia jobs directamente |
| Flow referencia job inexistente | 'jobs' => ['noexiste'] | Warning, job skipped |
| Job con type inválido | 'type' => 'inventado' | Error en parseo |
| Hook con evento git inválido | 'hooks' => ['inventado' => []] | Error |
| Flow con nombre de hook git | 'flows' => ['pre-commit' => [...]] | Error: nombre reservado |
| Options con processes negativo | 'processes' => -5 | Error o warning |
| Options con fail-fast no booleano | 'fail-fast' => 'quiza' | Error o warning |
| Custom job sin script | 'type' => 'custom' (sin script) | Error: script required |
| Job con paths array vacío | 'paths' => [] | No analiza nada, no crashea |
| Job duplicado en flow | 'jobs' => ['a', 'a'] | Se ejecuta 2 veces (verificar) |
3. Formatos de salida
| Test | Comando | Verificar |
|---|
| JSON válido | flow qa --format=json | Parseable. Estructura: {flow, success, totalTime, passed, failed, jobs[{name, success, time, output, fixApplied}]} |
| JUnit válido | flow qa --format=junit | XML válido: <testsuites><testsuite name tests failures time><testcase name time/></testsuite></testsuites> |
| Formato inválido | flow qa --format=csv | Warning "Unknown format" + fallback a texto |
| JSON en job individual | job X --format=json | Misma estructura JSON |
| Texto por defecto | flow qa | Output con colores, Results: X/Y passed in Xs |
| JSON dry-run | flow qa --dry-run --format=json | Incluye command en cada job. time: "0ms", output: "" |
| JSON sin dry-run | flow qa --format=json | Incluye command con el comando real ejecutado |
JSON con --fast y skipped | flow qa --fast --format=json (sin staged) | stdout es JSON parseable. Mensajes ⏩ was skipped salen por stderr, no contaminan el payload |
JSON executionMode | flow qa --format=json vs --fast vs --fast-branch | Campo executionMode refleja el modo real (full/fast/fast-branch) |
4. Flags especiales
| Flag | Comando | Qué verificar |
|---|
--exclude-jobs | flow qa --exclude-jobs=phpmd_src | El job NO aparece en results |
--only-jobs | flow qa --only-jobs=parallel_lint | Solo ese job se ejecuta |
--only-jobs CSV | flow qa --only-jobs=parallel_lint,phpcs_src | Solo esos 2 |
--only-jobs + --exclude-jobs | Ambos a la vez | Error: "cannot be used together" |
--only-jobs vacío | flow qa --only-jobs= | Ejecuta todos (no filtra) |
--only-jobs inexistente | flow qa --only-jobs=inventado | 0 jobs, exit 0 |
--only-jobs no en flow | flow lint --only-jobs=phpmd_src | 0 jobs (phpmd_src no está en lint) |
--dry-run en flow | flow qa --dry-run | Muestra nombre + comando, no ejecuta. Time=0ms |
--dry-run en job | job phpcs_src --dry-run | Muestra comando, no ejecuta |
--fail-fast | flow qa --fail-fast | Se detiene en primer fallo, restantes "skipped by fail-fast" |
--fast | flow qa --fast | Jobs acelerables analizan solo staged files |
--fast-branch | flow qa --fast-branch | Jobs acelerables analizan diff de rama vs principal |
--monitor | flow qa --monitor | Muestra "Thread monitor: peak ~N threads (budget: M)" |
--processes | flow qa --processes=4 | Cambia paralelismo |
--config | Cualquier comando con --config=path | Usa config indicada |
5. Combinaciones de flags
Los bugs más interesantes salen de combinar flags. Probar explícitamente:
| Combinación | Qué verificar |
|---|
--dry-run + --only-jobs | Solo muestra los jobs filtrados |
--dry-run + --format=json | JSON con campo command, sin ejecución |
--dry-run + --format=junit | XML válido con time=0 |
--dry-run + --monitor | No muestra monitor (budget=0 en dry-run) |
--dry-run + --fail-fast | No afecta (nada falla en dry-run) |
--only-jobs + --fail-fast | Solo ejecuta los jobs indicados, se detiene si falla |
--exclude-jobs + --format=json | JSON sin el job excluido |
6. Comando cache:clear
| Test | Comando | Qué verificar |
|---|
| Sin cachés | cache:clear --config=githooks-v3.php | Reporta cada path como "(not found)" |
| Con cachés fichero | Crear .phpcs.cache, .phpmd.cache, ejecutar | Borra, reporta "deleted" |
| Job específico | cache:clear phpcs_src --config=githooks-v3.php | Solo borra caché de phpcs |
| Flow name | cache:clear qa --config=githooks-v3.php | Borra cachés de todos los jobs del flow |
| Múltiples nombres | cache:clear phpcs_src phpmd_src | Borra ambas |
| Nombre inexistente | cache:clear inventado | Warning + exit 1 |
| Mix válido + inexistente | cache:clear phpcs_src inventado | Borra phpcs + warning + exit 1 |
| Directorio (phpstan) | Crear dir {sys_get_temp_dir}/phpstan/, ejecutar | Borra recursivamente |
| Config legacy | cache:clear (usa githooks.php v2) | Error: "requires v3 format" |
7. Validación profunda en conf:check
| Test | Qué verificar |
|---|
| Config válida (todo existe) | Tabla Jobs con columna Status: todos ✔ |
| Executable inexistente | Status: "executable 'X' not found" |
| Path inexistente | Status: "path 'X' not found" |
| Config file inexistente | Status: "config file 'X' not found" |
| Rules como fichero existente | ✔ |
Rules como nombres CSV (cleancode,codesize) | ✔ (no intenta validar como fichero) |
Standard como nombre simbólico (PSR12) | ✔ (no es un fichero, no debe dar warning) |
| Tool no instalada (phpunit, psalm) | Status: "executable 'X' not found" — error descriptivo, no crash |
8. Auto-detección de executablePath
| Test | CWD | Config | Resultado esperado |
|---|
| Con vendor/bin/ | /var/www/html3 | Job sin executablePath | Usa vendor/bin/phpstan |
| Sin vendor/bin/ | /tmp | Job sin executablePath | Cae a nombre simple (phpstan) |
| executablePath explícito | Cualquiera | 'executablePath' => '/custom/path' | Respeta el valor, no auto-detecta |
| Custom job | Cualquiera | 'type' => 'custom', 'script' => '...' | No aplica auto-detección |
| Script job | Cualquiera | 'type' => 'script' | No aplica auto-detección |
9. Tools no instaladas
El proyecto html3 no tiene phpunit ni psalm instalados. Verificar que el comportamiento es correcto:
| Test | Config | Resultado esperado |
|---|
| Job phpunit sin binario | 'type' => 'phpunit', 'config' => 'phpunit.xml' | Error descriptivo, no crash |
| Job psalm sin binario | 'type' => 'psalm', 'config' => 'psalm.xml' | Error descriptivo, no crash |
| conf:check con tool sin binario | Config con phpunit/psalm | Status: "executable not found" |
| dry-run con tool sin binario | --dry-run con phpunit | Muestra comando (no ejecuta, no falla) |
10. Hooks
| Test | Comando | Resultado esperado |
|---|
| Instalar hooks | hook --config=githooks-v3.php | Crea .githooks/ + configura core.hooksPath |
| Estado tras instalar | status --config=githooks-v3.php | Shows synced |
| Limpiar hooks | hook:clean | Borra .githooks/ + desactiva core.hooksPath |
| Estado tras limpiar | status --config=githooks-v3.php | Shows missing |
| hook:run sin hooks | hook:run pre-commit (config sin sección hooks) | Warning "No hooks section" |
| hook:run evento inexistente | hook:run inventado | Warning "No flows or jobs configured" |
| Commit real con hook OK | Instalar hook, stage CleanFile.php, commit | Hook dispara, pasa, commit se crea |
| Commit real con hook KO | Instalar hook, stage SyntaxError.php, commit | Hook dispara, falla, commit bloqueado |
Teardown hooks: git config --unset core.hooksPath; rm -rf .githooks/
11. Ejecución condicional (solo hooks)
Las condiciones van en la sección hooks como parte del HookRef. Se prueban via hook:run <evento>.
| Test | Config hooks | Resultado esperado |
|---|
only-on rama coincide | ['flow' => 'qa', 'only-on' => ['3.x-*']] en pre-commit | Ejecuta (rama 3.x-prueba coincide) |
only-on rama NO coincide | ['flow' => 'qa', 'only-on' => ['main', 'develop']] en pre-push | Skip |
exclude-on rama coincide | ['flow' => 'qa', 'exclude-on' => ['3.x-*']] en post-merge | Skip |
only-files con match | ['flow' => 'qa', 'only-files' => ['src/**/*.php']] + staged src/*.php | Ejecuta |
only-files sin match | ['flow' => 'qa', 'only-files' => ['tests/**/*.php']] + staged src/*.php | Skip |
exclude-files excluye | ['only-files' => ['src/**'], 'exclude-files' => ['src/Clean*']] + staged CleanFile.php | Skip |
exclude-on prevails | ['only-on' => ['3.x-*'], 'exclude-on' => ['3.x-prueba']] | Skip (exclude gana) |
12. Features v3.2 sin cobertura en release tests
Estas features están en el changelog de [3.2.0] pero no tienen test @group release. Probarlas a mano tras cada build nuevo del .phar hasta que se añadan al pipeline:
| # | Feature | Comando / setup | Qué verificar |
|---|
| 1 | cores: N propaga --parallel en phpcs | flow qa --dry-run --format=json con phpcs_src declarando cores: 2 | El jobs[].command del JSON contiene --parallel=2 |
| 2 | cores: N propaga --processes en paratest | flow qa --dry-run --format=json con paratest_all (type: paratest, cores: 4) | El command contiene vendor/bin/paratest ... --processes=4 |
| 3 | conf:check warn de conflicto cores vs flag nativo | Config con phpcs + parallel: 8 + cores: 2 | Output incluye 'cores' overrides 'parallel' |
| 4 | --output=PATH escribe fichero (los 4 formatos estructurados) | Para cada FORMAT ∈ {json, junit, codeclimate, sarif}: flow qa --format=FORMAT --output=/tmp/qa.out | Exit 0, fichero /tmp/qa.out contiene el payload esperado (JSON parseable, XML válido, …) |
| 5 | JUnit emite <skipped> para jobs skippados | flow qa --fast --format=junit con un job accelerable que no matchea staged files | Output contiene <skipped message="..."/> dentro del <testcase> correspondiente |
| 6 | GitLab CI annotations | GITLAB_CI=true flow qa (desde un test con error) | Output incluye markers section_start: / section_end: entre jobs |
| 7 | conf:check trunca commands a 80 chars | Config con un comando generado largo | Tabla de Jobs muestra … al final del comando; githooks job X --dry-run muestra el comando completo |
| 8 | Live streaming sequential (flow --processes=1) | flow qa --processes=1 con varios jobs | Cada job emite su output en tiempo real con separadores --- job_name --- (identificador literal del job) entre ellos |
| 9 | Dashboard TTY paralelo | flow qa --processes=4 en un terminal interactivo | Aparece dashboard con estados ⏺/⏳/✓/✗ y timers en vivo; al acabar, colapsa al resumen |
| 10 | --fast --format=<estructurado> no contamina stdout | flow qa --fast --format=json (sin staged) 1>stdout 2>stderr | stdout es JSON parseable; mensajes ⏩ was skipped solo en stderr |
| 11 | executionMode real en payload JSON | flow qa --format=json / --fast / --fast-branch | Campo executionMode refleja el modo del CLI, no siempre full |
| 12 | Code Climate location.path relativo | flow qa --format=codeclimate con errores en src/... | location.path es relativo al CWD (src/errors/...), no absoluto |
| 13 | SARIF artifactLocation.uri relativo | flow qa --format=sarif con errores en src/... | runs[].results[].locations[].physicalLocation.artifactLocation.uri relativo al CWD |
| 14 | Fail-fast lista skipped en JSON | flow qa --fail-fast --format=json (un job falla el primero) | jobs[] contiene TODOS los del plan; los no ejecutados aparecen con "skipped": true y "skipReason": "skipped by fail-fast" |
Cada item vale para los dos tiers (builds/php7.4/ y builds/). Priorizar los 1-4 (nuevos de gh-49-cores + flags de output más utilizados); 5-9 son útiles pero preexistentes.
13. Migración y compatibilidad legacy
| Test | Comando | Resultado esperado |
|---|
| Migrar config v2 válida | Copiar githooks.php a tmp, conf:migrate --config=tmp | Genera formato v3, backup |
| Migrar config ya v3 | conf:migrate --config=githooks-v3.php | Detecta que ya es v3 |
tool all full con config v2 | tool all full (usa githooks.php) | Ejecuta con deprecation warning |
tool all full con config v3 | tool all full --config=githooks-v3.php | Error o redirección a flow |
conf:check con config legacy | conf:check (usa githooks.php v2) | Tablas + warning de migración |
Paso 3: Limpiar
cd /var/www/html3
git config --unset core.hooksPath 2>/dev/null
rm -rf .githooks/ 2>/dev/null
git restore --staged . 2>/dev/null
git checkout -- . 2>/dev/null
git clean -fd 2>/dev/null
git checkout {master|2.x}
git branch -D {version}-prueba
git status
El paso 4 es obligatorio. No generar el reporte hasta confirmar que git status muestra working tree limpio (sin staged, sin modificados, sin untracked). Si queda algo sucio, limpiarlo antes de continuar.
Protección: nunca borrar master ni 2.x.
Teardown durante los tests
Cuando un test modifica ficheros (ej: echo >> file && git add file para probar only-files), el teardown inmediato tras ese test debe deshacer tanto el stage como el working tree:
git restore --staged <file> && git checkout -- <file>
git checkout -- <file> solo deshace cambios en working tree, no limpia el staging area. Si hiciste git add, necesitas git restore --staged primero.
Formato de reporte
Al terminar, generar una tabla resumen. Usar la columna Resultado para distinguir entre estados:
| # | Área | Test | Resultado | Severidad | Notas |
|---|
| 1 | flow | --only-jobs un job | OK | | Solo ejecuta el indicado |
| 2 | conf:check | standard PSR12 | BUG CORREGIDO | Media | Falso positivo: validaba nombre simbólico como fichero |
| 3 | flow | --exclude-jobs | BUG | Alta | Se define en signature pero no filtra |
Valores de Resultado:
- OK: funciona como se espera
- BUG: no funciona, pendiente de corregir
- BUG CORREGIDO: encontrado y corregido durante el testing
- SKIP: no se pudo probar (falta dependencia, entorno, etc.)
Severidades (solo para BUG/BUG CORREGIDO):
- Critica: crashea, pierde datos, rompe la ejecución normal
- Alta: funcionalidad documentada que no funciona
- Media: edge case mal manejado pero con workaround
- Baja: cosmético, mensaje confuso, comportamiento no ideal
