En los anteriores tutoriales creamos todo el entorno para trabajar con TypeScript y configurar un ciclo de integración continua (CI) con Parcel, Prettier, Estlint, etc.
Aquí abajo podrás seguir la serié de tutoriales anteriores que he estado realizando :
- Primero pasos con TypeScript con Microsoft Visual Studio Code
- Integración de GitHub / Git / GibHub Desktop y MS Visual Studio Code
- Instalación de Jest con TypeScript y MS Visual Studio Code
- Instalación de Prettier en MS Visual Studio Code
- Introducción a Parcel
- Verificación de formato de código con Eslint
- Configurando Github Actions junto con TypeScript, Jest, Parcel, Eslint y Prettier
También me gustaría que vieras este video de 2 minutos para entender dónde estamos y a dónde vamos.
En lo que pretendo estar entretenido las próximas semanas para jugar con #TypeScript. Recomendaciones de @cesalberca Me ha dicho que, cuando haya cacharreado, en un rato lo montamos todo ?? pic.twitter.com/gdfBRFMQiT
— Roberto Canales Mora (@rcanalesmora) January 8, 2020
Mi equipo es Mac
macOS Catalina
Versión 10.15.2
MacBook Pro (15-inch, 2018)
Procesador 2,9 GHz Intel Core i9 de 6 núcleos
Memoria 32 GB 2400 MHz DDR4
Gráficos Intel UHD Graphics 630 1536 MB
Este CI estaba incompleto porque no hacía despliegue de la aplicación a los usuarios finales.
Vamos a completar esta etapa publicando nuestra aplicación en GitHub Pages, veréis que sencillo es. Como siempre, empezad leyendo la documentación https://pages.github.com/.
Parto de esta estructura de proyecto donde tengo una carpeta src con las fuentes y Parcel me creará, al construir, una carpeta llamada dist con los js y html que han resultado de transpirar TypeScript.
Tenemos que partir de un repositorio público o de una versión pro de GitHub, por lo que voy a hacer público mi repositorio. Esto se hace desde los settings del propio repositorio.
Vamos a la sección “peligrosa” de setting, al final comprobais que lo tengo público porque aparece «Make private» (Hacerlo privado).
Un poco más arriba en la sección de settings nos vamos a GitHub Pages y vemos las opciones que tenemos.
Hay varias opciones para desplegar nuestro proyecto y hacerlo utilizable para el público. Leed esto con atención para que no sea confuso:
– Directamente podemos hacer que la rama master sea la rama por defecto. Si hacemos esto, cada vez que subamos cualquier push los usuarios lo pueden usar. De este modo podría valernos como entorno de pruebas en desarrollo, compile o no (complete o no el ciclo de CI).
– Podemos crear una carpeta de docs y, en el ciclo de integración continua, una vez que todo ha funcionado, podríamos añadir una nueva acción que sea copiar de la carpeta de dist a la de docs. Con esto, solo se actualiza la página cuando compila.
Mirar la pantalla, hay una tercera opción (realmente la que queramos pero sin complicarnos la vida para lo que queremos hacer).
Esta tercera opción consiste en crear una rama llamada gh-pages. De este modo, podemos tener los cambios estables (los que pasan las reglas de CI) en una rama aislada (llamemos de stagging o prepo).
Me voy a GitHub Desktop y la creo (podría hacerse desde cualquier sitio, el propio UI Web de GitHub).
A partir de ese momento se activa una opción más en las opciones de GitHub Pages, que es publicar lo que haya en esa rama:
Es lo que vamos a hacer. Cada vez que hagamos push, vamos a copiar los ficheros de la carpeta dist (recordar que es donde pone los ficheros Parcel) a la rama gh-pages.
Podríamos hacer algo más fino todavía, y es que cuando creemos una etiqueta con un patrón, solamente sea cuando se active este comando de Workflow de Github Actions, pero de momento nos da igual. Vamos con lo simple.
Para ello, vamos a usar una acción que se llama GitHub Pages Deploy https://github.com/marketplace/actions/github-pages-deploy
Vamos a nuestra carpeta de Workflow en el código.
Y añadimos estas líneas.
|
– name: Deploy en GitHubPages con secreto |
|
uses: maxheld83/ghpages@v0.2.1 |
|
env: |
|
GH_PAT: ${{ secrets.GH_PAT }} |
BUILD_DIR: ./dist
Quedando:
Ahora tenemos que seguir las instrucciones y crear un secreto llamado GH_PAT con permisos de repositorio para que podamos realizar la acción.
Si no lo hacemos falla el ciclo de CI porque no tiene permisos para escribir.
Para añadir el secreto primero nos vamos a la configuración del usuario.
Le damos añadir Personal Access Tokens.
Elegimos permisos solamente de repositorio.
Y nos generará una clave que veremos solamente una vez. La copias para tenerla disponible en el portapapeles (Y no se la compartas a nadie ni la pongas en un tutorial :-))
Luego te vas a los settings de tu repositorio a la sección secretos.
Y creas un secreto con el nombre GH_PAT pegando el código en VALUE que te ha generado, el token.
Por lo que ya tenemos nuestro secreto.
Y ahora, al hacer push o modificar el fichero .yml corre nuestro ciclo de CI, copiando de la rama master todos los ficheros a la raíz de la rama Pages.
Aquí vemos nuestros ficheros.
Y podemos comprobar con nuestra URL que funciona.
Bueno, ya tenemos la infraestructura para programar en el front y desplegar. Ahora nos hacen falta un poco más de conocimientos para completar nuestro juego.
Aquí te dejo el siguiente tutorial:
