GitHub Actions
Curso interactivo completo
1 / 8
Módulo 01 — Introducción

¿Qué es GitHub Actions?

GitHub Actions es la plataforma de automatización CI/CD nativa de GitHub. Te permite definir flujos de trabajo (workflows) como código YAML que se ejecutan automáticamente cuando ocurren eventos en tu repositorio.

💡 Gratis para repositorios públicos. Para privados incluye 2 000 min/mes en el plan Free, con runners Linux.
⚡
CI/CD integrado
Construye, testea y despliega desde el mismo repo sin herramientas externas.
🧩
Marketplace de actions
+21 000 actions reutilizables creadas por la comunidad y GitHub.
🖥️
Runners propios
Conecta tu propia máquina o servidor como runner self-hosted.
🔒
Secrets seguros
Credenciales cifradas accesibles en tus workflows sin exponerlas.
📤 Push / PR
→
🎯 Trigger
→
⚙️ Runner
→
✅ Deploy
Módulo 02 — Estructura

Anatomía de un workflow

Un workflow es un archivo .yml ubicado en .github/workflows/. Está compuesto por 5 elementos clave.

yaml .github/workflows/mi-workflow.yml
1# 1️⃣ NOMBRE del workflow (aparece en la UI de GitHub)
2name: CI Pipeline
3
4# 2️⃣ EVENTO que lo dispara
5on:
6 push:
7 branches: ["main"]
8
9# 3️⃣ JOBS (tareas paralelas o secuenciales)
10jobs:
11 build: # ID del job
12
13 # 4️⃣ RUNNER donde se ejecuta
14 runs-on: ubuntu-latest
15
16 # 5️⃣ STEPS (comandos secuenciales)
17 steps:
18 - uses: actions/checkout@v4 # Action reutilizable
19 - name: Correr tests
20 run: npm test # Comando shell
🎯 Regla de oro: un archivo = un workflow. Puedes tener múltiples archivos en .github/workflows/ para separar CI, CD, releases, etc.
Módulo 03 — Eventos

Eventos y triggers

La clave on: define cuándo se ejecuta tu workflow. Selecciona un evento para ver su configuración YAML:

Selecciona un trigger

  


  

    
      
EventoCuándoCaso de uso

    
    
      
pushAl hacer push a ramasCI en cada commit

      
pull_requestAl abrir/actualizar PRValidar antes de merge

      
scheduleCron (tiempo fijo)Reportes, backups nocturnos

      
workflow_dispatchManual desde la UIDeploy a demanda

      
releaseAl publicar un releaseCD automático en producción

    
  


  

    
    
  







  

    
    Módulo 04 — Ejecución
  

  
Jobs y steps

  

    Los jobs se ejecutan en paralelo por defecto. Los steps dentro de un job son secuenciales.
    Usa needs: para crear dependencias.
  


  

    

      
Jobs en paralelo

      
Jobs con dependencia

      
Steps condicionales

    


    

      

        

          yaml
          paralelo.yml
          
        

        


1jobs:


2  test-frontend:               # ┐


3    runs-on: ubuntu-latest        # │ corren en


4    steps:


5      - run: npm run test:frontend # │ paralelo


6


7  test-backend:                # │


8    runs-on: ubuntu-latest        # ┘


9    steps:


10      - run: pytest tests/

        

      

    


    

      

        

          yaml
          dependencia.yml
          
        

        


1jobs:


2  test:


3    runs-on: ubuntu-latest


4    steps:


5      - run: npm test


6


7  deploy:


8    needs: test              # ← espera que 'test' termine OK


9    runs-on: ubuntu-latest


10    steps:


11      - run: ./deploy.sh production

        

      

    


    

      

        

          yaml
          condicionales.yml
          
        

        


1steps:


2  - name: Build


3    run: npm run build


4


5  - name: Deploy solo en main


6    if: github.ref == 'refs/heads/main'


7    run: ./deploy.sh


8


9  - name: Notify si falló


10    if: failure()


11    run: curl -X POST $SLACK_WEBHOOK -d '{"text":"❌ Build falló"}'

        

      

    

  


  

    
    
  







  

    
    Módulo 05 — Runners
  

  
GitHub-hosted vs Self-hosted runners

  

    El runner es la máquina que ejecuta tus jobs. Elige según tus necesidades de costo, rendimiento y acceso a red.
    Haz clic en una opción para ver su configuración:
  


  

    
    

      runs-on: ubuntu-latest
      
✓

      
GitHub-hosted runner

      

        ✅ Cero configuración

        ✅ Mantenido por GitHub

        ✅ Limpio en cada ejecución

        ⚡ ubuntu / windows / macos

        💲 Consume minutos del plan
      

      

        

          
yamluso

          


runs-on: ubuntu-latest   # Ubuntu 22.04


runs-on: windows-latest  # Windows Server 2022


runs-on: macos-latest    # macOS 14 (M1)


runs-on: ubuntu-22.04    # versión fija

          

        

        

          ℹ️
          Incluye Git, Docker, Node, Python, Java, .NET y más pre-instalados.
        

      

    


    
    

      runs-on: self-hosted
      
✓

      
Self-hosted runner

      

        ✅ Tu infraestructura

        ✅ Acceso a red privada

        ✅ Sin límite de minutos

        ⚡ Linux / Windows / macOS / ARM

        🔧 Tú lo mantienes y configuras
      

      

        

          
yamluso con labels

          


# Label único


runs-on: self-hosted




# Con labels específicos


runs-on: [self-hosted, linux, gpu]




# Por grupo


runs-on:


  group: mi-grupo-prod


  labels: [linux, x64]

          

        

      

    

  


  

    
CaracterísticaGitHub-hostedSelf-hosted

    
      
Configuración🟢 Ninguna🟡 Manual

      
Costo💲 Minutos del plan🟢 Solo infraestructura

      
Red privada🔴 No🟢 Sí

      
Hardware custom🔴 No🟢 GPU, ARM, etc.

      
Mantenimiento🟢 GitHub🔴 Tú

    
  


  

    
    
  







  

    
    Módulo 06 — Seguridad
  

  
Secrets y variables de entorno

  

    Nunca escribas credenciales en el YAML. Usa Secrets para datos sensibles y Variables para configuración reutilizable.
  


  

    

      
Definir secrets

      
Usar en workflow

      
Variables de entorno

    


    

      

        

          
1

          

            
Ir a Settings del repositorio

            
GitHub repo → Settings → Secrets and variables → Actions

          

        

        

          
2

          

            
Crear nuevo secret

            
Clic en New repository secret. Nombre en UPPER_SNAKE_CASE. El valor queda cifrado y nunca se muestra de nuevo.

          

        

        

          
3

          

            
Niveles de secrets

            

              Repository — solo ese repo

              Environment — por ambiente (prod/staging)

              Organization — compartido entre repos
            

          

        

      

    


    

      

        
yamlsecrets-en-workflow.yml

        


jobs:


  deploy:


    runs-on: ubuntu-latest


    steps:


      - name: Deploy a producción


        env:                              # exponer como env var


          API_KEY: ${{ secrets.API_KEY }}


          DB_PASS: ${{ secrets.DB_PASSWORD }}


        run: ./deploy.sh




      - name: Login Docker Hub


        uses: docker/login-action@v3


        with:                             # con: pasa directamente


          username: ${{ secrets.DOCKER_USER }}


          password: ${{ secrets.DOCKER_TOKEN }}

        

      

    


    

      

        
yamlenv-vars.yml

        


# Global (todo el workflow)


env:


  NODE_ENV: production


  APP_PORT: '3000'




jobs:


  build:


    runs-on: ubuntu-latest


    env:                        # Nivel job


      BUILD_DIR: dist/


    steps:


      - run: echo "Puerto: $APP_PORT"


      - run: echo "Dir: $BUILD_DIR"


        # Variables de contexto de GitHub:


      - run: echo ${{ github.sha }}

        

      

    

  


  

    ⚠️
    Nunca hagas print de un secret. GitHub los enmascara en los logs, pero es mala práctica y puede haber formas de extraerlos.
  


  

    
    
  







  

    
    Módulo 07 — Ejemplo real
  

  
CI/CD completo — Node.js + Docker

  

    Workflow production-ready: tests → build imagen Docker → push a registry → deploy en servidor. Usa ubuntu-latest.
  


  

    

      yaml
      .github/workflows/ci-cd.yml
      
    

    


name: CI/CD Pipeline




on:


  push:


    branches: ["main"]


  pull_request:


    branches: ["main"]




env:


  REGISTRY: ghcr.io


  IMAGE_NAME: ${{ github.repository }}




jobs:




  # ── JOB 1: Tests ────────────────────────────


  test:


    runs-on: ubuntu-latest


    strategy:


      matrix:


        node-version: [18.x, 20.x]


    steps:


      - uses: actions/checkout@v4


      - name: Setup Node.js ${{ matrix.node-version }}


        uses: actions/setup-node@v4


        with:


          node-version: ${{ matrix.node-version }}


          cache: 'npm'


      - run: npm ci


      - run: npm test -- --coverage


      - run: npm run lint




  # ── JOB 2: Build & Push imagen Docker ───────


  build-push:


    needs: test


    runs-on: ubuntu-latest


    if: github.ref == 'refs/heads/main'


    permissions:


      contents: read


      packages: write


    steps:


      - uses: actions/checkout@v4


      - name: Login al registry


        uses: docker/login-action@v3


        with:


          registry: ${{ env.REGISTRY }}


          username: ${{ github.actor }}


          password: ${{ secrets.GITHUB_TOKEN }}


      - name: Build y push


        uses: docker/build-push-action@v5


        with:


          push: true


          tags: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:latest




  # ── JOB 3: Deploy en servidor ───────────────


  deploy:


    needs: build-push


    runs-on: ubuntu-latest


    environment: production   # requiere aprobación manual


    steps:


      - name: SSH deploy


        uses: appleboy/ssh-action@v1


        with:


          host: ${{ secrets.SERVER_HOST }}


          username: ${{ secrets.SERVER_USER }}


          key: ${{ secrets.SSH_PRIVATE_KEY }}


          script: |


            docker pull ghcr.io/${{ github.repository }}:latest


            docker compose up -d --force-recreate

    

  


  

    
    
  







  

    
    Módulo 08 — Self-hosted
  

  
Configurar un self-hosted runner

  

    Instala el agente en cualquier máquina Linux (o Windows/macOS). Una vez conectado, usa runs-on: self-hosted en tus workflows.
  


  

    

      
1

      

        
Ir a Settings → Actions → Runners → New self-hosted runner

        
GitHub genera un token temporal para registrar el runner. El token expira en 1 hora.

      

    

    

      
2

      

        
Descargar e instalar el agente

        

          
bashLinux x64

          


# Crear directorio y descargar


mkdir actions-runner && cd actions-runner


curl -o actions-runner-linux-x64-2.316.1.tar.gz \


  -L https://github.com/actions/runner/releases/download/v2.316.1/\


  actions-runner-linux-x64-2.316.1.tar.gz


tar xzf ./actions-runner-linux-x64-2.316.1.tar.gz

          

        

      

    

    

      
3

      

        
Configurar y registrar

        

          
bashregistro

          


# Reemplaza ORG, REPO y TOKEN con tus valores


./config.sh \


  --url https://github.com/ORG/REPO \


  --token AABBCC... \


  --name mi-servidor-prod \


  --labels linux,x64,produccion \


  --work _work

          

        

      

    

    

      
4

      

        
Ejecutar como servicio (systemd)

        

          
bashservicio

          


# Instalar como servicio systemd


sudo ./svc.sh install


sudo ./svc.sh start




# Verificar estado


sudo ./svc.sh status


# → ● actions.runner.ORG-REPO.mi-servidor-prod.service


#      Active: active (running)

          

        

      

    

    

      
5

      

        
Usar en tu workflow

        

          
yamlworkflow usando el runner

          


jobs:


  deploy:


    runs-on: [self-hosted, linux, produccion]


    steps:


      - uses: actions/checkout@v4


      - run: docker compose up -d --build

          

        

      

    

  


  

    ⚠️
    Seguridad: nunca uses self-hosted runners en repos públicos. Cualquier persona podría ejecutar código en tu máquina a través de un PR.
  


  
  

    
🧠 Quiz final: ¿Qué label se usa para ejecutar un workflow en un runner self-hosted?

    

      
      
      
      
    

    

  


  

    🎉
    ¡Completaste el curso! Ya sabes cómo crear workflows, manejar triggers, usar secrets y configurar runners. El siguiente paso: revisa el marketplace de Actions y reutiliza las +21k actions existentes.