Antes de empezar. El workflow valida ya la corrección del marcado. En esta sesión se incorporan dos comprobaciones adicionales, la disponibilidad de los recursos enlazados y la conformidad del formato, que detectan defectos con anterioridad a la fusión.
Evaluación inicial · sin apuntes
- ¿Cuántos enlaces contiene actualmente tu portfolio y cuándo se verificó por última vez que todos resuelven?
- Dos personas escriben el mismo documento HTML con sangrías distintas. ¿Qué criterio determina cuál de las dos es la correcta?
- Si una comprobación automática emite un resultado negativo sobre un elemento que en realidad es correcto, ¿qué procedimiento debe seguirse?
Se explica
25 minutos · explicación conceptual y demostración técnica
Dos defectos objetivos: enlaces no resolubles y formato inconsistente
Un enlace que no resuelve y un archivo con estilos de sangría heterogéneos constituyen dos defectos ajenos a la competencia en programación, pero perceptibles de inmediato en cualquier revisión profesional.
Ambos comparten una propiedad determinante: son objetivamente verificables. Establecer si un recurso responde a una petición, o si un archivo se ajusta a un formato declarado, no exige juicio profesional alguno, de modo que corresponden por completo al ámbito de la validación automatizada.
Granularidad de los jobs: una comprobación por criterio
La definición actual del workflow contiene un único job. En esta sesión pasará a contener tres, decisión de diseño que conviene fundamentar:
Agrupación en un único job
Se publica una sola comprobación. Ante un resultado negativo resulta necesario abrir el registro para determinar si el defecto corresponde al marcado, a los enlaces o al formato. Además, el fallo de una etapa interrumpe las siguientes, por lo que los defectos se descubren de forma secuencial, uno por iteración.
Un job por criterio de validación
Se publican tres comprobaciones identificadas por su nombre y ejecutadas en paralelo. La pull request informa de qué criterio incumple el cambio sin necesidad de consultar el registro, y una sola ejecución revela todos los defectos presentes.
Los jobs de un workflow se ejecutan en paralelo salvo declaración explícita de dependencias mediante needs, de modo que la duración total no equivale a la suma de las tres validaciones, sino a la de la más lenta.
Normalización del formato mediante un formateador
Formateador (formatter)
Herramienta que reescribe el código fuente conforme a un conjunto fijo de reglas de estilo. Su valor no reside en la superioridad técnica de ese estilo concreto, sino en dos consecuencias: la discusión sobre el formato desaparece del proceso de revisión, y las diferencias que muestra una pull request corresponden a cambios funcionales y no a reordenaciones de espacios en blanco.
Ejecutado en modo de comprobación no modifica ningún archivo: se limita a informar de cuáles no se ajustan al formato declarado y a terminar con código de error.
Tratamiento de los falsos positivos
La situación se producirá, en particular durante la verificación de enlaces: determinados servidores responden con un código de error a cualquier petición que no proceda de un navegador convencional, aunque el recurso exista y el enlace sea correcto. Ante un falso positivo caben dos respuestas, de las cuales solo una resulta admisible:
| Respuesta ante el falso positivo | Consecuencia sobre el pipeline |
|---|---|
| Eliminar la comprobación o suprimir su carácter obligatorio | El pipeline deja de ejercer control sobre ese criterio y la reactivación queda indefinidamente pendiente |
| Declarar la excepción documentando su motivo | La comprobación permanece activa, la excepción es explícita y puede auditarse en cualquier revisión posterior |
Un pipeline del que se desactivan reglas cada vez que emiten un resultado incómodo queda reducido a una definición decorativa. Las excepciones se declaran y se justifican.
Se trabaja
140 minutos · trabajo práctico guiado sobre el proyecto base
Bloque A · Job de verificación de enlaces
Trabajo individual, con issue y rama previas
Incorpora este job a .github/workflows/ci.yml, al mismo nivel de indentación que el ya existente:
enlaces:
name: Enlaces vivos
runs-on: ubuntu-latest
steps:
- name: Descargar el repositorio
uses: actions/checkout@v4
- name: Comprobar los enlaces
uses: lycheeverse/lychee-action@v2
with:
args: --no-progress --max-retries 2 "**/*.html"
fail: trueLa indentación es significativa en YAML: enlaces se declara con dos espacios, alineado con html. Una indentación mayor lo convertiría en contenido del job anterior e invalidaría la definición.
Abre la pull request y analiza el resultado. Es previsible que la comprobación señale algún enlace del menú de navegación dirigido a una sección todavía no implementada: ese resultado no constituye un falso positivo, sino la detección correcta de un recurso no resoluble.
Si un enlace externo falla pese a ser correcto
Verifícalo primero en el navegador. Si el recurso responde, se trata de un servidor que rechaza las peticiones automatizadas. Declara la excepción añadiendo su dirección al argumento --exclude y documenta el motivo en la descripción de la pull request. Una exclusión sin justificación escrita impide determinar, meses después, si el recurso sigue disponible.
Bloque B · Job de verificación del formato
Trabajo individual, sobre la misma rama o sobre una nueva
formato:
name: Formato
runs-on: ubuntu-latest
steps:
- name: Descargar el repositorio
uses: actions/checkout@v4
- name: Preparar Node
uses: actions/setup-node@v4
with:
node-version: 22
- name: Comprobar el formato
run: npx --yes prettier@3 --check "**/*.{html,css,json,md}"Esta comprobación emitirá un resultado negativo en su primera ejecución, dado que el proyecto no se ha normalizado previamente. Aplica el formato en local con la misma herramienta en modo de escritura:
npx --yes prettier@3 --write "**/*.{html,css,json,md}"Examina las diferencias antes de confirmar los cambios: conviene identificar con precisión qué ha modificado la herramienta sobre el código fuente.
Aislamiento del commit de normalización
Una operación de formateo modifica un número elevado de líneas sin alterar el comportamiento del documento. Si esas modificaciones se confunden con un cambio funcional en la misma confirmación, la revisión por pares debe localizar el cambio real entre cientos de líneas de indentación desplazada. El reformateo se registra por tanto en un commit independiente y con un mensaje explícito: «Aplicar el formato de Prettier a todo el proyecto».
Bloque C · Incorporación de las dos comprobaciones obligatorias
Trabajo individual, posterior a la fusión
Siguiendo el procedimiento de la sesión anterior: fusiona las pull requests y accede después a Settings → Rules → Rulesets → main protegida → Edit → Require status checks para incorporar Enlaces vivos y Formato. El conjunto queda en cuatro comprobaciones obligatorias.
Lista de verificación del bloque C
- Una pull request muestra cuatro comprobaciones identificadas con nombres legibles.
- Las cuatro figuran como obligatorias en el ruleset de la rama principal.
- Es posible determinar cuál de las cuatro ha fallado sin abrir el registro de ejecución.
Bloque D · Sección de proyectos
Trabajo individual, con enlaces reales
Implementa la sección de proyectos del portfolio. En esta fase contendrá una única ficha, la del propio portfolio: descripción, tecnologías empleadas, enlace al repositorio y enlace a la versión publicada. Constituye el primer proyecto documentado y verificable del expediente.
Incorpora asimismo los enlaces externos previstos: GitHub, LinkedIn si procede y dirección de contacto. El job de verificación detectará los que estén mal formados antes de su publicación.
on admite schedule.Cierre
15 minutos · comprobación del resultado
Autoevaluación conceptual · sin consulta de apuntes
- ¿Por qué tres jobs independientes y no tres etapas dentro de un único job?
- ¿La ejecución de tres jobs triplica la duración del pipeline?
- Un enlace externo falla en el CI pero responde correctamente en el navegador. ¿Qué procedimiento corresponde aplicar y cuál queda descartado?
- ¿Por qué la normalización del formato se registra en un commit independiente?
- ¿Qué aporta un formateador a un equipo, si su estilo no es objetivamente superior a otro?
Ver respuestas
1 · Para que cada criterio de validación disponga de una comprobación identificada por su nombre y para que todos los defectos se manifiesten en una misma ejecución, en lugar de secuencialmente.
2 · No: los jobs se ejecutan en paralelo, de modo que la duración total equivale a la del job más lento.
3 · Corresponde declarar la exclusión de ese recurso concreto documentando el motivo en la pull request. Queda descartado eliminar la comprobación o suprimir su carácter obligatorio.
4 · Porque modifica un número elevado de líneas sin alterar el comportamiento, y su mezcla con un cambio funcional impide una revisión efectiva.
5 · La eliminación de la discusión sobre el estilo y la garantía de que las diferencias mostradas en una pull request corresponden a cambios reales.
Antes de la sesión 5
- El portfolio integra cabecera, presentación y proyectos, incorporados mediante pull request.
- Las cuatro comprobaciones se encuentran en estado correcto sobre
main. - Debe constar en el repositorio una imagen propia o del proyecto: la sesión 5 trabajará sobre ella.