Lanzamiento automatizado para Android mediante acciones de GitHub

Cada vez que construimos una aplicación y enviamos el código a GitHub, es obvio que podríamos querer crear una versión para que la gente pueda usarla sin construir el proyecto en su entorno local. Esta versión puede ser un APK para un proyecto de Android o un sitio web alojado para proyectos de desarrollo web. Vamos a hablar sobre el proyecto de Android aquí. Entonces, todo esto se puede lograr usando la sección Versiones, donde generamos una nueva versión cada vez que hacemos una modificación productiva al código configurando el Nombre de la versión, la Etiqueta de la versión y la descripción adecuada para cada versión.

Repetir las mismas tareas puede ser estresante y monótono a veces. Así que aquí viene la función de crear lanzamientos automatizados usando GitHub Actions. Cada vez que tenemos una solicitud de extracción que se fusiona, o si el mantenedor del código envía algunos cambios al código base, se desenstring el proceso de compilación del código, la creación del APK y su publicación. Como resultado, se libera el proceso de creación manual de la versión. Para comenzar, sugeriría tener una comprensión básica de cómo construir canalizaciones de CI usando GitHub Actions. Cree un archivo .yml llamado build-and- release.yml en el directorio .github/workflows en el directorio raíz del proyecto. Comience a escribir el código en ese archivo.

name: Build and Release

on:
 push:
   branches:
     - master
   tags:
     - "v*"

jobs:
 apk:
   name: Generate APK
   runs-on: ubuntu-latest
   steps:
     - name: Checkout
       uses: actions/checkout@v2.4.0
     - name: Setup JDK
       uses: actions/setup-java@v2.5.0
       with:
         distribution: temurin
         java-version: "11"
     - name: Set execution flag for gradlew
       run: chmod +x gradlew
     - name: Build APK
       run: bash ./gradlew assembleDebug --stacktrace
     - name: Upload APK
       uses: actions/upload-artifact@v1
       with:
         name: apk
         path: app/build/outputs/apk/debug/app-debug.apk

 release:
   name: Release APK
   needs: apk
   runs-on: ubuntu-latest
   steps:
     - name: Download APK from build
       uses: actions/download-artifact@v1
       with:
         name: apk
     - name: Create Release
       id: create_release
       uses: actions/create-release@v1
       env:
         GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
       with:
         tag_name: ${{ github.run_number }}
         release_name: ${{ github.event.repository.name }} v${{ github.run_number }}
     - name: Upload Release APK
       id: upload_release_asset
       uses: actions/upload-release-asset@v1.0.1
       env:
         GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
       with:
         upload_url: ${{ steps.create_release.outputs.upload_url }}
         asset_path: apk/app-debug.apk
         asset_name: ${{ github.event.repository.name }}.apk
         asset_content_type: application/zip

name es el nombre completo del flujo de trabajo, que se mostrará en la lista de flujos de trabajo en la pestaña de acciones. on define cuándo se activará el flujo de trabajo. Aquí estamos dispuestos a activar el flujo de trabajo tan pronto como insertemos el código en la rama maestra o se especifique una nueva etiqueta con v como prefijo. Como sabemos, cada flujo de trabajo tiene algunos trabajos que deben ejecutarse a medida que se activa el flujo, por lo tanto, aquí hemos creado dos trabajos con títulos como apk y release . 

En el primer trabajo, especificamos el nombre como Generate APK , el primer paso es configurar el entorno y se especifica mediante la ejecución. Aquí estamos usando ubuntu-latest alojado en GitHub. A continuación, hemos especificado las acciones de pago que verificarán el repositorio en $GITHUB_WORKSPACE, para que el flujo de trabajo que estamos escribiendo pueda acceder a él. Luego configuramos JDK junto con build apk. Tan pronto como esto esté hecho, buscaremos el apk del directorio app/build/outputs/apk/debug/app-debug.apk  y lo subiremos a las secciones de artefactos de GitHub. 

Todo esto resume nuestra tarea inicial de compilar el apk, recuperarlo del directorio donde se generó y subirlo a la sección de artefactos. Ahora vamos a crear una versión usando esta aplicación en el siguiente trabajo, es decir , una versión con el nombre Release APK. 

En primer lugar, especificamos que para que se ejecute este trabajo, se debe completar el trabajo con el título apk, lo que se hace escribiendo necesidades: apk. Como hicimos en el trabajo anterior, aquí también configuramos el entorno como ubuntu-latest. Subimos el apk a la sección de artefactos en el trabajo anterior, así que ahora descargamos ese apk y comenzamos a crear un lanzamiento.

Para crear un lanzamiento, este trabajo debe tener el GITHUB_TOKEN proporcionado por el entorno virtual y se puede acceder simplemente escribiendo ${{ secrets.GITHUB_TOKEN }}. Ahora, para cada lanzamiento creado, debe haber un nombre de etiqueta y un nombre de lanzamiento para ese lanzamiento en particular. Entonces, para hacerlo dinámico, especificamos tag_name como número de ejecución, es decir, ${{ github.run_number }} y release_name como nombre del repositorio junto con el número de ejecución, es decir, ${{ github.event.repository.name }} v${{ github .run_number }}. 

Ahora se ha creado el lanzamiento y queremos cargar el apk de lanzamiento. Entonces, nuevamente, para hacer esto, debemos proporcionar GITHUB_TOKEN al trabajo. Definimos upload_url que es la URL para cargar el recurso como ${{steps.create_release.outputs.upload_url }} , asset_path desde donde se extraerá el apk como apk/app-debug.apk, asset_name para configurar el nombre del apk como ${{ github.event.repository.name }}.apk y asset_content como application/zip.

Cuando termine de escribir el flujo de trabajo, confirme los cambios y vaya a la pestaña Acciones, verá un flujo de trabajo en ejecución.

Cuando ambos trabajos, es decir, Generar APK y Liberar APK, muestren una marca de verificación verde, vaya a Código y, en el lado derecho, en la sección Lanzamientos, verá un lanzamiento publicado con el nombre como sucedió con el nombre del repositorio con v1.

Todo esto concluye nuestra tarea de escribir un flujo de trabajo en el que cada vez que se envían algunos cambios a la rama principal, se activa, lo que finalmente crea una versión y la carga en la sección Versiones del repositorio de GitHub. Como resultado, ya no estamos obligados a crear la versión manualmente.