CI de acciones de Github para proyectos Swift

Github introducido CI y CD basados ​​en acciones. Le permite automatizar cómo analiza, construye, prueba e implementa sus proyectos en cualquier plataforma, incluidos Linux, macOS y Windows.

Estaba entusiasmado con esta noticia y no puedo esperar para probarlo. Mi idea era automatizar la construcción y las pruebas unitarias de los proyectos de Swift.

Hay dos tipos de acciones y debemos saber la diferencia antes de comenzar.

Contenedor Docker vs JS

Originalmente, todas las acciones se basaban en Docker y usaban la sintaxis HCL para los flujos de trabajo. Las acciones basadas en Docker se ejecutan solo en un entorno virtual Linux. Con el anuncio de CI/CD, Github lanzó acciones basadas en JavaScript y una nueva sintaxis YAML para flujos de trabajo.

Para proyectos de iOS, solo puede usar acciones JS porque deben ejecutarse en macOS. Además, el uso de una acción de JavaScript simplifica el código de acción y se ejecuta más rápido que una acción de contenedor de Docker.

¡Luces! ¡Cámara! ¡Acción de Github!

Como ejemplo usaré Estilo de texto. Es un marco para formatear cadenas atribuidas. Comencemos con una configuración completa e inspeccionémosla paso a paso:

on: pull_request
name: Test
jobs:
  test:
    name: Test
    runs-on: macOS-latest
    strategy:
        matrix:
          destination: ['platform=iOS Simulator,OS=12.2,name=iPhone X', 'platform=tvOS Simulator,OS=12.2,name=Apple TV 4K']
    steps:
      - name: Checkout
        uses: actions/checkout@master
      - name: Build and test
        run: |
          cd Texstyle
          xcodebuild clean test -project Texstyle.xcodeproj -scheme Texstyle -destination "${destination}" CODE_SIGN_IDENTITY="" CODE_SIGNING_REQUIRED=NO ONLY_ACTIVE_ARCH=NO
          bash <(curl -s https://codecov.io/bash)
        env: 
         destination: ${{ matrix.destination }}

Al principio, debe seleccionar un evento para activar el flujo de trabajo. Mi flujo de trabajo se activa en cualquier solicitud de extracción en el repositorio. Opcionalmente, puede etiquetar el flujo de trabajo con name.

Los flujos de trabajo deben contener al menos un trabajo. Mi flujo de trabajo contiene solo un trabajo para probar. Es posible ejecutar hasta 20 trabajos simultáneamente por repositorio en todos los flujos de trabajo.

Los trabajos se ejecutan en máquinas host virtuales que se especifican con runs-on. en mi caso es macOS-latest, porque quiero usar xcodebuild. Es una herramienta estándar para desarrolladores de Apple y solo funciona en macOS.

Texstyle es compatible con iOS y tvOS, por lo que quiero ejecutar xcodebuild con dos destinos. Para especificar diferentes variaciones, usé strategy.matrix. Agregué dos simuladores con versiones reales del sistema operativo.

Y el último paso es agregar pasos 🙃. solía checkout acción para acceder a los contenidos del repositorio. Puede especificar la versión de las acciones después del signo @ con una versión de lanzamiento, una rama o una confirmación específica.

Todo está listo para la prueba. yo añadí run con comandos bash para cambiar el directorio actual, ejecutar xcodebuild y enviar datos de cobertura de código a códigocov. Para usar variables de matriz, agregué env con el nombre de variable requerido.

Para leer más sobre la sintaxis del flujo de trabajo, consulte la documentación.

En comparación con Travis CI, mi configuración se veía así:

language: swift
osx_image: xcode10.2

env:
  matrix:
   - DESTINATION="platform=iOS Simulator,OS=12.2,name=iPhone X"
   - DESTINATION="platform=tvOS Simulator,OS=12.2,name=Apple TV 4K"

before_script: cd Texstyle

script:
   - xcodebuild clean test -project Texstyle.xcodeproj -scheme Texstyle -destination "$DESTINATION" CODE_SIGN_IDENTITY="" CODE_SIGNING_REQUIRED=NO ONLY_ACTIVE_ARCH=NO
   
after_success:
  - bash <(curl -s https://codecov.io/bash)

¡Eso es todo! Aquí hay un ejemplo de registros en vivo:
1*vtXE2WRpFjZpPwMx3EIVJg.png

Pero ese no es el final, ¡es solo el comienzo! Supongamos que queremos rechazar las solicitudes de extracción si hay errores o advertencias de pelusa. La herramienta de pelusa más popular para Swift es pelusaveloz. Por ahora es posible ejecutarlo y ver advertencias en los registros que no es suficiente. Sería genial ver anotaciones de SwiftLint Violations a través de API de comprobaciones de GitHub, o incluso han sugerido cambios. Y las acciones permiten usar esta API fácilmente.

Conclusión

En cuanto a mí, Github Actions CI es un cambio de juego. Está profundamente integrado en el servicio. Y las acciones impulsadas por la comunidad permiten reutilizar escenarios comunes.

Resumamos mi experiencia con pros y contras.

Ventajas:

  • Varios disparadores para flujos de trabajo. Solicitudes de extracción, repositorios fijos, estados de tarjetas de proyectos, eventos programados, etc.
  • Velocidad. Según los registros de Texstyle, las últimas compilaciones fueron de 2 minutos y 12 segundos en Travis CI y de 1 minuto y 8 segundos en Github CI.
  • Software preinstalado. Las imágenes de macOS tienen fastlane, swiftlint, Cocoapods, Carthage, etc.
  • Mercado. Hay un montón de acciones desarrolladas por la comunidad. Puedes reutilizar cualquiera de ellos.
  • Precios. Por supuesto, es gratis para código abierto. Los límites de tiempo se ven bastante bien: 2000 minutos para el plan gratuito y 3000 minutos con un plan Pro que incluye repositorios privados 😏.

Contras:

  • Todavía en beta. Las primeras acciones se escribieron en sintaxis HCL. Se eliminará la compatibilidad el 30 de septiembre. Y tal vez no sea el final, la sintaxis de YAML también se puede actualizar. Así que prepárese para migrar sus acciones antes del lanzamiento público.
  • Depuración. Es difícil depurar flujos de trabajo como cualquier servicio de CI. Debe activar el evento relacionado y esperar todos los pasos. No es posible probarlo localmente, ni siquiera validar la sintaxis del flujo de trabajo.
  • Documentación. Uno de los objetivos de este artículo es aclarar el beneficio de Actions para mí y probarlo en un proyecto real. Tuve muchos errores no obvios, la documentación oficial y StackOverflow no ayudaron. Por ejemplo, un comando de ejecución multilínea no funcionará sin un name etiqueta. Creo que los flujos de trabajo de código abierto ayudarán a evitar errores de volcado y manejarán casos extremos en el futuro.

¡Gracias por leer! Si tiene alguna pregunta o idea de flujos de trabajo, no dude en dejar comentarios o hacerme ping en Twitter. @iosartem.

Referencias

Automatización de su flujo de trabajo con GitHub Actions
Acciones de Github
Acciones impresionantes

Similar Posts

Leave a Reply

Your email address will not be published.