Quien revisa debería leer el documento que cambia un pull request, no un diff de asteriscos. Esta acción publica cada archivo Markdown modificado como página renderizada y comenta los enlaces en el pull request.
Leer la configuración en la documentación
Si no se le da una lista de archivos, la acción pregunta a git qué archivos Markdown tocó el pull request, publica cada uno como página de solo lectura y comenta una tabla con nombres de archivo, número de palabras y enlaces. Los archivos que la rama borró se saltan, así que quitar un documento no hace fallar la ejecución.
Es una acción compuesta, `action.yml` en la raíz del repositorio público, y lo que ejecuta es el cliente de línea de comandos del mismo repositorio: ningún contenedor que descargar, ninguna dependencia que instalar, y el mismo renderizado que dan el sitio y la API.
El comentario lleva el título Markdown preview. Quien revisa abre cada enlace en un navegador como cualquier otra página, sin app y, en un enlace, sin cuenta — y así alguien que nunca abre el diff puede revisar los textos.
Un diff es la vista correcta para el código y la equivocada para la prosa. Enseña qué palabras cambiaron y oculta si la sección se sigue leyendo bien, si una tabla cuadra o si una lista numerada vuelve a empezar en uno a mitad de camino. La página renderizada responde a eso de un vistazo, y quien no escribe Markdown puede, por fin, leerla.
Hay un workflow completo para copiar en `examples/publish-markdown.yml`. Se ejecuta con `pull_request` y un filtro `paths` para `**.md`, así que un pull request que no cambia Markdown no arranca ningún runner. El checkout necesita `fetch-depth: 0`, porque los archivos modificados se calculan frente al commit base del pull request, y el job necesita `pull-requests: write` para publicar el comentario.
El paso en sí es `uses: raudarlabs/transformpipe@main` con una sola entrada, `api-key: ${{ secrets.TP_API_KEY }}`. La clave es una clave API de TransformPipe guardada como secreto del repositorio, y la acción se la pasa al cliente en una variable de entorno y no como argumento, así que no forma parte del comando que se escribe en el registro.
`files` recibe rutas separadas por espacios en lugar de la lista de archivos modificados; así publica la acción en un push a una rama en vez de en un pull request. `share` es `link` por defecto, `people` solo para lectores nombrados, o `none` para mantener privados los documentos. `merge: true` encadena los archivos en un solo documento, con el nombre que dé `name`.
`replaces` registra un único documento como nueva versión de uno anterior, `comment: false` omite el comentario, y `host` apunta a otro despliegue.
Vuelven dos salidas para los pasos siguientes: `urls`, los enlaces publicados uno por línea, y `documents`, la respuesta de la API para cada documento, en JSON. Si no hay nada que publicar, la acción lo dice, deja `urls` vacía y `documents` como lista vacía, y termina con éxito, así que un paso posterior se puede condicionar a `urls` en vez de fallar.
Cada ejecución publica documentos nuevos en lugar de sobrescribir los anteriores, así que el enlace de un comentario más antiguo sigue mostrando lo que decía ese commit. El precio es un documento por archivo y ejecución en la cuenta, que guarda 5.000 documentos y 250 MB; las vistas previas antiguas se pueden borrar desde el historial.
Publicar un enlace público requiere una dirección de correo confirmada en la cuenta, y hasta que lo esté, el paso falla con esa frase. Un pull request que viene de un fork se ejecuta sin los secretos del repositorio, así que ahí el paso no tiene clave; sáltalo con `if: github.event.pull_request.head.repo.fork == false`.