Looking for an English version?

Configuración de Runners Estáticos

Para aprovechar al máximo CI, en algún momento necesitarás configurar un runner. Los Runners Estáticos son un punto de partida sencillo. Se trata de una máquina (virtual o física) que está en funcionamiento de manera constante. Tus trabajos se ejecutan directamente en esta máquina, lo que facilita la configuración y la resolución de problemas.

Para CI, normalmente uso GitLab, por lo que estas instrucciones están orientadas a GitLab (también incluiré información para usuarios de GitHub).En mi blog tengo varios artículos sobre cómo configurar GitLab Runners. La información está distribuida en varios artículos y algo fragmentada, así que intentaré resumir todo en un solo lugar aquí. Si prefieres video, tengo uno de mí guiando a Casey a través del proceso. Se hizo antes de este tutorial, por lo que puede que no coincida exactamente.

Aquí hay un diagrama que muestra la configuración básica:

¿Cuántos Runners necesito?

Esta es una pregunta común. Es posible tener un solo runner con múltiples versiones de LabVIEW instaladas. Sin embargo, en el pasado, múltiples versiones de LabVIEW no siempre han funcionado bien juntas, por lo que no lo recomiendo. Mi recomendación es usar un runner por cada versión de LabVIEW o uno por proyecto si tus proyectos requieren controladores de terceros u otros requisitos únicos. Esto mantiene las cosas mejor aisladas. Esto puede resultar en muchas máquinas, por lo que las máquinas virtuales son tus aliadas aquí, o Docker si te sientes valiente, aunque eso es otro tema complejo. Puedes simplificar un poco el proceso teniendo una máquina común con Windows 10 o 11 como punto de partida. Probablemente no quieras clonar toda la máquina, ya que eso puede causar problemas. Es mejor simplemente copiar el disco de la VM y crear una nueva VM a partir de él.

Supuestos

Aquí estoy haciendo algunos supuestos.
Asumo que estás utilizando Windows (debería ser similar para Windows 10 o 11).

También voy a configurar esto usando Git Bash en lugar de PowerShell.
No me agrada Microsoft y no sé PowerShell, pero sí conozco Bash, así que eso es lo que voy a usar.
Si prefieres usar PowerShell, la configuración inicial será un poco más fácil (ya que es el shell predeterminado para runners de GitLab en Windows).
Sin embargo, puede que necesites ajustar algunos archivos YAML y scripts.

También asumo que estás usando VIPM Pro o la Edición Comunitaria.
Necesitas una de estas versiones para que la herramienta VIPC Applier funcione correctamente.

Punto de Inicio

Como runner, generalmente querrás una máquina separada de tu máquina de desarrollo.
Esto podría ser un portátil o escritorio de repuesto, una VM ejecutándose en tu propio escritorio o servidor, o un VPS en algún proveedor como Amazon, Vultr o Digital Ocean.

Necesitarás suficiente potencia para cargar tu proyecto y ejecutar una compilación.
La máquina también necesitará acceso a Internet para poder hacer ping a gitlab.com (o si alojas GitLab localmente, a la URL de tu servidor GitLab).

Deberías considerar mantenerla en una red separada e aislada de tu red principal, porque ejecutar una compilación básicamente abre un reverse shell.

NOTA: Si recién estás comenzando y experimentando con CI, una solución sencilla es instalar GitLab Runner en tu máquina de desarrollo.
No es lo ideal, pero reduce la barrera de entrada y te permite ver fácilmente lo que está ocurriendo.
En ese caso, probablemente puedas omitir la sección sobre configurar el script para que se ejecute al iniciar sesión y la configuración de autologon.

Acceso a la Máquina del Runner

Deberás poder iniciar sesión en el runner y ver la interfaz gráfica para la configuración, instalación y solución de problemas.

Para una máquina física, esto debería ser fácil.
Para máquinas remotas, RDP funciona mejor, pero también se puede usar VNC, MSP360 o TeamViewer.

No expongas RDP ni VNC directamente a Internet, ya que no es seguro.
En su lugar, utiliza un túnel cifrado como SSH, VPN, WireGuard, Nebula, etc.

Instalación Inicial de Software

Asumo que estás usando Windows, por lo que querrás instalar la versión correspondiente de Windows y activar Escritorio Remoto (si es el método que usarás para acceder).

Deberás instalar Git para Windows junto con Git Bash. Las opciones por defecto son adecuadas.

Luego, instala NIPM y úsalo para instalar la versión correcta de LabVIEW, VIPM, DAQmx y cualquier otro controlador que necesites.
También querrás instalar algunos paquetes básicos de VIPM, como G-CLI y la API de VIPM.
Además, instala las herramientas de SAS-GCLI que planees utilizar.

Si cuentas con la edición Pro o Community de VIPM, puedes usar la herramienta VIPC Applier para instalar paquetes como parte de tu pipeline de CI.
Si no es así, deberías instalar los paquetes necesarios en este momento.

Si vas a usar Python para ejecutar scripts de construcción o utilidades, ahora es un buen momento para instalarlo junto con los paquetes de Python necesarios.

No es recomendable instalar extras innecesarios. Esta máquina no se utilizará para nada más que ejecutar builds. Ejecutar una build básicamente abre un reverse shell, por lo que no debes tener información sensible en ella más allá de tu código.

Verificación Inicial

Debes abrir manualmente VIPM y LabVIEW para asegurarte de que no aparezcan diálogos de licencias. Si aparecen, ocúpate de ellos.

Verifica que VIPM pueda conectarse a tu versión de LabVIEW abriendo VIPM y yendo al cuadro de diálogo de Configuración.

También debes comprobar que G-CLI esté instalado correctamente y pueda conectarse a LabVIEW. Para ello, escribe en Git Bash: g-cli echo -- "Hello World" en Git Bash y verifica que devuelva "Hello World". Si no lo hace, revisa tu $PATH y asegúrate de que contenga el directorio de G-CLI. Es posible que necesites agregar una línea de export a tu archivo .bashrc.

Configuración de GitLab Runner

Instalación de GitLab Runner

Las instrucciones para instalar el programa gitlab-runner proporcionadas por GitLab son bastante buenas. Sigue los primeros 3 pasos.

¡LUEGO DETENTE!

Ahora, ve a la página de configuración de CI/CD de tu proyecto. Ve a la sección de Runners y haz clic en los 3 puntos junto al botón “Create project Runner” para abrir un menú. Selecciona “Show runner installation and registration instructions”.

Luego selecciona Windows, desplázate hacia abajo y copia el texto del cuadro de texto “Command to Register Runner”. Abre PowerShell como administrador: haz clic en el botón de Windows, busca PowerShell y debería haber un botón para iniciarlo como administrador a la derecha. Haz clic en él. Luego escribe cd C:\gitlab-runner para cambiar al directorio de gitlab runner. Después pega lo que copiaste antes y presiona Enter.

Sigue las indicaciones e ingresa los valores solicitados. Si hay algo entre corchetes [], ese es el valor predeterminado y presionar Enter simplemente lo acepta. Haz eso para la clave y en cualquier otro lugar donde tenga sentido. Asegúrate de seleccionar shell como tu executor cuando se te pida.

También se te pedirá que le des un nombre y le asignes una etiqueta. Puedes cambiar estos valores más tarde a través de la interfaz web. En general, querrás etiquetar un runner con el nombre de un proyecto específico o basándote en las versiones de software instaladas. Las etiquetas se usan para determinar qué trabajos puede ejecutar GitLab en ese runner en particular. Solo debes seguir las instrucciones hasta el punto en que te indique instalarlo como servicio. Si quieres poder depurar activamente y ver lo que está ocurriendo, no querrás hacer eso. Así que detente después del paso 5 y no continúes con el paso 6.

Configuración de GitLab Runner para usar Git Bash en lugar de PowerShell

NOTA: Esta sección describe cómo configurar GitLab Runner para usar Git Bash. Si quieres usar PowerShell, puedes omitirla.

Primero, necesitamos ayudar a GitLab Runner a encontrar Git Bash. Agrega un archivo bash.cmd en tu directorio de usuario (el usuario que ejecuta GitLab Runner) con el siguiente contenido:

@”C:\Program Files\Git\usr\bin\bash.exe” -l

A continuación, debemos asegurarnos de que las rutas de inicio estén configuradas correctamente con formato estilo Linux. En tu archivo config.toml de GitLab Runner (está en el directorio donde instalaste GitLab Runner), cambia el shell a bash y agrega rutas estilo Linux para builds_dir y cache_dir. Eso es todo. Consulta el ejemplo a continuación.

[[runners]]
  name = “windows”
  url = “https://your.server.name”
  token = “YOUR_SECRET_TOKEN”
  executor = “shell”
  shell = “bash”
  builds_dir=”/c/gitlab-runner/builds/”
  cache_dir=”/c/gitlab-runner/cache/”

NOTA sobre las rutas: Aquí estamos usando rutas estilo Linux, pero cuando pases rutas como parámetros a las herramientas de g-cli (es decir, los parámetros después de --) necesitarás usar rutas de Windows.

Ejecutar como Usuario

Crea un archivo batch con la siguiente línea.

”C:\Program Files\Git\bin\sh.exe” --login -i -c “cd /c/Gitlab-Runner && ./gitlab-runner.exe run”

Guárdalo en un lugar conveniente, como el Escritorio, y dale un nombre significativo como “Start GitLab Runner.bat”. Al ejecutar este archivo batch se abrirá una ventana de consola. Una vez que comience un trabajo, verás todas las ventanas que abre: la pantalla de carga de LabVIEW y cualquier VI que abra. Así que si se queda colgado en algún diálogo, lo sabrás.

Configurar para Ejecutar al Inicio

Para ejecutar el script al inicio (cuando el usuario actual inicia sesión), coloca un acceso directo en la carpeta de Inicio de Windows. Puedes encontrar la carpeta de inicio de Windows presionando la tecla Windows + R y escribiendo shell:startup en el cuadro de diálogo resultante.

Configurar el Usuario con Inicio de Sesión Automático

Lo último que generalmente hago es configurar el usuario con inicio de sesión automático; de lo contrario, cada vez que la máquina se reinicie, tendrás que iniciar sesión antes de que gitlab-runner pueda arrancar. La forma de hacerlo en Windows es usando netplwiz. Presiona la tecla Windows + R y escribe netplwiz. Se abrirá una ventana de Cuentas de Usuario. Deberías ver una casilla de verificación en la parte superior que dice “Users must enter a user name and password to use this computer.” Simplemente desmárcala.

NOTA: Es posible que no veas esa casilla. Si no la ves, puedes intentar agregar una clave de registro. Copia el código a continuación. Abre un símbolo del sistema como administrador. Pega y ejecuta el código. Reinicia. La casilla debería aparecer ahora. Si no es así, hay otras posibles soluciones; simplemente búscalas en Google.

reg ADD “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\PasswordLess\Device” /v DevicePasswordLessBuildVersion /t REG_DWORD /d 0 /f

En este punto, generalmente reinicio el runner y simplemente lo observo para asegurarme de que al arrancar no quede esperando una contraseña de Windows y que el script batch se ejecute al inicio.

Verificación en GitLab

Verificar la Conexión

Si inicias sesión en tu proyecto y vas a la configuración de CI/CD, y el runner está en funcionamiento (es decir, has ejecutado el archivo batch que creamos), deberías verlo en la lista de runners asignados.

Asignar Runners y Cambiar Etiquetas

Una vez que tengas un runner en funcionamiento y conectado a tu servidor de GitLab, es fácil realizar cambios a través de la interfaz web. Puedes cambiar el nombre y las etiquetas. También puedes habilitarlo para diferentes proyectos (por defecto están bloqueados a un proyecto específico, por lo que primero debes desbloquearlo). Puedes hacer todo esto haciendo clic en el botón de editar junto al runner para abrir el editor de configuración del runner.

¡Listo!

Una vez que hayas completado todos los pasos anteriores, tu runner debería estar listo para funcionar.