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
1 · Issue y rama de funcionalidad. Selecciona del tablero o crea la issue «Validar enlaces en el pipeline de CI» y genera su rama desde main debidamente actualizada:
git switch main
git pull
git switch -c 8-ci-enlaces2 · Incorporación del job de enlaces. Abre .github/workflows/ci.yml y añade el nuevo trabajo bajo la clave jobs:, exactamente al mismo nivel de sangría que el job html existente:
jobs:
html:
# ... job existente de la sesión 3 ...
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.
3 · Confirmación y apertura de la pull request. Registra el cambio en Git y publícalo en tu repositorio remoto:
git add .github/workflows/ci.yml
git commit -m "Anadir comprobacion automatica de enlaces con Lychee"
git push -u origin 8-ci-enlacesAbre la pull request indicando Closes #8 (o el número de tu issue) y analiza la ejecución en la sección de comprobaciones.
Al desplegar el paso Comprobar los enlaces en el registro de la ejecución, Lychee muestra un resumen final con las rutas analizadas y sus códigos de respuesta:
- Cannot find file o HTTP 404: el enlace apunta a un archivo local que aún no existe (por ejemplo, una página del menú que todavía no has creado) o a una URL externa que ha dejado de responder. Es la detección legítima de un fallo, no un error de configuración de la acción.
- HTTP 403 o 999: la dirección web existe, pero el servidor remoto rechaza la petición automatizada del runner (falso positivo).
Si un enlace externo falla pese a ser correcto (falsos positivos)
Verifícalo primero en el navegador. Si el recurso responde, se trata de un servidor que rechaza las peticiones automatizadas procedentes de la nube. Declara la excepción añadiendo su dirección al argumento --exclude y documenta el motivo en la descripción de la pull request:
args: --no-progress --max-retries 2 --exclude "https://linkedin.com/.*" "**/*.html"Una exclusión sin justificación escrita impide determinar, meses después, si el recurso sigue disponible o si se introdujo por descuido.
Bloque B · Job de verificación del formato
Trabajo individual · Fusión previa de enlaces y nueva rama
Tras revisar y fusionar la pull request de enlaces mediante Squash and merge, sincroniza tu rama principal local y bifurca la nueva tarea:
git switch main
git pull
git switch -c 9-ci-formato1 · Incorporación del job de formato. Añade la comprobación a .github/workflows/ci.yml. Debe situarse bajo jobs:, alineada con html y enlaces:
jobs:
html:
# ... job existente de la sesión 3 ...
enlaces:
# ... job existente del bloque A ...
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}"Prettier aplica de forma predeterminada su conjunto normativo estándar; no requiere archivo de configuración explícito para este proyecto.
2 · Observación del fallo en el pipeline. Confirma y envía el workflow a la rama remota antes de normalizar los archivos en local:
git add .github/workflows/ci.yml
git commit -m "Anadir comprobacion de formato con Prettier"
git push -u origin 9-ci-formatoAbre la pull request. Esta comprobación emitirá un resultado negativo (aspa roja) en su primera ejecución, dado que el repositorio contiene archivos aún no formateados. Accede al detalle del check para comprobar cómo la herramienta enumera cada archivo con discrepancias de sangría o espaciado.
3 · Normalización del código en el entorno local. Aplica el formato en tu máquina con la misma herramienta en modo de escritura:
npx --yes prettier@3 --write "**/*.{html,css,json,md}"Conserva las comillas dobles en "**/*.{html,css,json,md}" para que la terminal interprete la lista de extensiones sin expandirlas prematuramente. En PowerShell, utiliza npx.cmd si tu entorno bloquea la ejecución de scripts.
Examina las diferencias con git diff 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».
4 · Confirmación y paso a verde. Registra el formateo de forma aislada y sube el cambio:
git add -A
git commit -m "Aplicar el formato de Prettier a todo el proyecto"
git pushComprueba que la pull request vuelve a ejecutarse automáticamente y que el check Formato concluye ahora con éxito.
Bloque C · Incorporación de las comprobaciones obligatorias
Trabajo individual, posterior a la fusión
Siguiendo el procedimiento de la sesión anterior: fusiona la pull request y accede después a Settings → Rules → Rulesets → main protegida → Edit → Require status checks para incorporar Enlaces vivos y Formato junto al ya existente HTML válido.
En el buscador de comprobaciones, busca y selecciona cada check por su nombre exacto (Enlaces vivos y Formato, tal como figuran en la clave name de cada job), no por el nombre del workflow CI ni por el identificador del archivo YAML. Guarda los cambios con Save changes. El conjunto de validación previa queda en tres comprobaciones obligatorias.
Lista de verificación del bloque C
- Una pull request muestra tres comprobaciones identificadas con nombres legibles (
HTML válido,Enlaces vivosyFormato). - Las tres figuran como obligatorias en el ruleset de la rama principal.
- Es posible determinar cuál de las tres 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, perfil profesional y dirección de contacto. El job de verificación detectará los que estén mal formados antes de su publicación.
Gestión de enlaces a redes sociales y plataformas con protección anti-bot
Determinadas plataformas (como LinkedIn) bloquean sistemáticamente las peticiones automatizadas procedentes de runners en la nube devolviendo códigos HTTP 403 o 999. Si un enlace responde correctamente en el navegador pero hace fallar el check de Enlaces vivos, aplica la directiva --exclude documentada en el bloque A.
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 tres comprobaciones de validación (
HTML válido,Enlaces vivosyFormato) se encuentran en estado correcto sobremainjunto con el despliegue. - Debe constar en el repositorio una imagen propia o del proyecto: la sesión 5 trabajará sobre ella.