GitHub Actions

Taller

Objetivos

• Establecer un pipeline de CI usando GitHub Actions.
• Analizar los beneficios de configurar un pipeline de CI.

Pre-requisitos

• Haga un fork del siguiente repositorio https://github.com/isis3710-uniandes/react-ci
• Realice un clone del repositorio forkeado y ejecute los siguientes comandos:

npm install npm run start

• Verifique el funcionamiento de la aplicación de pokemons en la siguiente url : http://localhost:3000

Ejemplo básico de Github Actions

• Cree un workflow para el repositorio forkeado. Para esto cree un directorio en la raíz del repositorio con el nombre .github/workflows, dentro de este directorio cree el archivo hello.yml . El archivo hello.yml sólo ejecutará la impresión por consola de "Hello ISIS3710", tal como se muestra en el siguiente archivo:

name: Hello ISIS3710!

on:
  push:
    branches:
      - master

jobs:
  hello_world_job:
    runs-on: ubuntu-18.04
    steps:
      - name: Say hello
        run: |
          echo "Hello ISIS3710"

• Identificar y entender cada una de las lineas del archivo hello.yml. Para esto puede ir a la documentación

• Realizar commit y push de la workflow hello.yml. Luego, ir a la pestaña de Actions del repositorio forkeado y revisar que se haya ejecutado el job definido en el workflow.

• Agregue un nuevo paso (step) al job para obtener la fecha actual por consola. Recuerda que el ambiente es Ubuntu. Documentación date

• Realice el commit y push y verifique la ejecución del job en GitHub.

Ejecución proyecto React con Github Actions

En esta sección, se espera configurar un workflow para instalar las dependecias del proyecto de React y ejecutar ESLint para verficar el estilo de código de la aplicación.

• Cree un nuevo archivo en el directorio .github/workflows con el nombre de pipeline.yml. Este archivo se encargará de configurar el job con los distintos pasos para hacer la instalación de dependencias y la ejecución del linter. Copie las siguientes lineas de código en el archvo pipeline.yml y realice commit y push.

name: Pipeline React

on:
  push:
    branches:
      - master

jobs:
  simple_deployment_pipeline:
    runs-on: ubuntu-18.04
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v1
        with:
          node-version: '12.x'
      - name: npm install 
        run: npm install  
      - name: lint
        run: npm run eslint

• Verifique para que sirve las expresiones uses: actions/setup-node@v1 y - uses: actions/checkout@v2 en la documentación.
• Al ir a la pestaña de actions en Github debería aparecer varios errores en el linter y la ejecución del job debe ser fallida.
• Realice la corrección de todos los errores en la aplicación para obtener una ejecución exitosa.

Build

• Agregue el siguiente paso para realizar la construcción de la carpeta build. Esta carpeta contiene todos los js minificados y optimizados para despliegues a producción.

  - name: Build
    run: npm run build

• Verifique la correcta construcción en la pestaña Actions del repositorio después de hacer commit y push de los cambios.

Trabajando con Pull Request

Una parte intersante de GitHub Actions es que permite hacer builds de las aplicaciones no sólo cuando se hacen push a las ramas sino también cuando se abren o se actualizan nuevos Pull Request(PR). Esto permite establecer unas condiciones mínimas para aprobar o no un PR, como por ejemplo, el 100% de las pruebas existentes deben ser satisfactorias o la cobertura de pruebas no debe ser inferior a un porcentaje establecido. En el proyecto fork, realice los siguientes cambios para configurar el trigger del workflow cuando se abra un nuevo PR o se actualice.

  on:
  push:
    branches:
      - main
  pull_request:
    branches: [main]
    types: [opened, synchronize]
  ...

• Cree una nueva rama a partir de master que se llame feature/update-readme. En esta rama, agregue su nombre, código y correo electrónico al finalizar el readme. Cree un pull request de esta rama hacia master y verifique que el workflow empieza a ejecutar el job establecido anteriormente.

• Una vez finalizado el job, el PR deberá tener un nuevo label donde muestre el resultado del job (Para este caso debe ser exitoso).

• Realice algún cambio en el PR que rompa la construcción (ESLint rules) suba los cambios y verifique el resultado.

Suba a BS el link del repositorio con todas las indicaciones anteriores.