En esta segunda parte, crearé un nuevo workflow para la rama master, por lo que podemos enviar un debug apk artifact para GitHub y usarlo para pruebas internas.

Si estas buscando una introducción de GitHub Actioons y el primer ejemplo, aquí esta el link.

Crear un archivo workflow 

Crea el archivo .github/workflows/android-feature.yml con el siguiente contenido:

name: Android Master Branch CI

on:	
  push:
    branches:
      - 'master'

jobs:
  test:
    name: Run Unit Tests
    runs-on: ubuntu-18.04

    steps:
      - uses: actions/checkout@v1
      - name: set up JDK 1.8
        uses: actions/setup-java@v1
        with:
          java-version: 1.8
      - name: Unit tests
        run: bash ./gradlew test --stacktrace

  apk:
    name: Generate APK
    runs-on: ubuntu-18.04

    steps:
      - uses: actions/checkout@v1
      - name: set up JDK 1.8
        uses: actions/setup-java@v1
        with:
          java-version: 1.8
      - name: Build debug APK
        run: bash ./gradlew assembleDebug --stacktrace
      - name: Upload APK
        uses: actions/upload-artifact@v1
        with:
          name: app
          path: app/build/outputs/apk/debug/app-debug.apk

Entendiendo el workflow 

Nombre del Workflow

name: Android Feature Branch CI

La primera parte es el nombre del workflow

Definición de eventos

on:
  push:
    branches:
      - '*'
      - '!master

Avanzando a los jobs section, puedes ver que se tiene dos de ellos. Primero, test es lo mismo que  el ejemplo anterior, por lo que se omitirá la explicación. Segundo, apk es nuevo y su propósito principal es construir una aplicación de Android en APK, para que pueda instalarse en un dispositivo móvil. En la primera parte definimos name y en que máquina virtual debe ejecutarse este job (runs-on).

apk:
    name: Generate APK
    runs-on: ubuntu-18.04

Luego están los pasos. Los dos primeros son los mismos que en test de job, permitimos que el workflow acceda a los archivos del repositorio establecemos la versión de JDK. Un tercer job es nuevo, pero similar al anterior test. Esta vez no estamos ejecutando el test task de Gradle, pero assembleDebug resultará en un archivo APK de Android integrado.

   - name: Build debug APK
        run: bash ./gradlew assembleDebug --stacktrace

El último paso garantiza que el archivo APK creado se conservará (no se eliminará) una vez que finalice el workflow. en el with element indicamos que archivo (en ruta) se debe guardar. GitHub llama tales artefactos de archivos persistentes.

- name: Upload APK
        uses: actions/upload-artifact@v1
        with:
          name: app
          path: app/build/outputs/apk/debug/app-debug.apk

Después de esta explicación, estamos listos. Lo único que falta es crear una rama, extraer una solicitud y fusionarla, para que el workflow se pueda activar ya que el evento es un push over master.

Una cosa importante es que ambos jobs se están ejecutando al mismo tiempo. en futuros blogs se explicara como encadenar jobs usando needs, el resulado de un job puede ser usado como un unput o requirement de otro job,

Después de un par de minutos, obtuvimos un resultado exitoso en ambos jobs, ademas, el archivo apk de artefactos se puede descargar, aparecerá un icono justo encima del registro de la consola de workflow

Conclusión 

En esta parte, presento un par de nuevos conceptos y acciones que pueden usarse como steps, como por ejemplo: actions/upload-artifact@v1. En la próxima publicación integraré Firebase App Distribution para generar APK y enviarlo a grupos de testers tan pronto como se combine un pull request, para que se puedan realizar pruebas internas.

Referencias

•  GitHup Actions dor Android: First Approach