Crear un plugin Xojo con Acciones de GitHub

A continuación encontrarás traducido al Castellano el artículo escrito originalmente por Jürg Otter y publicado en el Blog oficial de Xojo.

Como parte de la iniciativa Año de Código 2025 de Xojo, el tema correspondiente al mes de Febrero se centra en Bases de Datos; lo que viene como anillo al dedo con el trabajo que he realizado recientemente correspondiente al proyecto de código abierto CubeSQLPlugin. Este artículo comparte mis hallazgos en cuanto a la automatización del proceso de compilación mediante el uso de las Acciones de GitHub como parte del flujo de trabajo.

Los plugins de Xojo son añadidos que amplían la funcionalidad del entorno de desarrollo de Xojo; permitiendo que los desarrolladores añadan más funcionalidades, integren librerías de terceros y mucho más.

Escribir un Plugin de Xojo

Este artículo asume que ya estás familiarizado con el SDK de Plugins Xojo y se centra en la automatización de las compilaciones del plugin. Si no tienes experiencia en el desarrollo de plugins, consulta los recursos disponibles en la carpeta “Extras”, los tutoriales de YouTube y también los recursos proporcionados por el Foro de Xojo.

Este artículo toma como punto de partida mi anterior blog sobre las Acciones de GitHub con Xojo y también implica a Docker, el cual ha sido parte de mis anteriores artículos. Por tanto, lee dichos artículos para saber qué es un flujo de trabajo basado en las Acciones de GitHub, y para qué se utilizan los archivos .yaml de la carpeta .github/workflows.

Crear un Plugin Xojo

Dado a que Xojo es un entorno de desarrollo multiplataforma, un plugin de Xojo ha de compilarse para todas las plataformas soportadas (Windows, MacOS, Linux), y también todas las arquitecturas (Intel/ARM, 32/64 bits).

Todas las partes del plugin (los .dll de Windows, las .dylib de macOS, y los .so de Linux) se empaquetan en un archivo .xojo_plugin.

Uno de los retos es contar con un entorno para compilar todos ellos. A primera vista puede parecer que debas usar un Mac, un equipo Windows y también un entorno Linux (si bien cualquiera de estos pueden ser simplemente máquinas virtuales). Y también podrías pensar que existen múltiples pasos que deban realizarse manualmente: compilar el código fuente del plugin sobre los diferentes equipos, copiar todas las partes compiladas del plugin y ensamblar el archivo .xojo_plugin final.

Sin embargo, no se requiere de todo ello. Puedes compilar un plugin Xojo sin necesidad de contar con tu propio equipo; de forma totalmente automatizada. Las Acciones de GitHub nos proporcionan todo lo necesario.

Ejemplo: CubeSQLPlugin

Echaremos un vistazo a este plugin de código abierto.

CubeSQLPlugin es una extensión para el entorno de desarrollo Xojo que permite a los desarrolladores utilizar CubeSQL: un sistema de gestión de bases de datos relacionales de alto rendimiento, creado sobre el motor de bases de datos SQLite.

El plugin se utiliza en las Herramientas de Administración de código abierto para CubreSQL, y que están escritas en Xojo: CubeSQL Web Admin y CubeSQL (Desktop) Admin.

Internamente, el plugin utiliza LibreSSL para las conexiones TLS de los clientes de bases de datos sobre CubeSQL Server.

Esto significa que primeramente las librerías LibreSSL han de compilarse para todas las plataformas. Sólo entonces puede compilarse el código fuente del plugin nuevamente para todas las plataformas soportadas y, por último, todas las partes del plugin pueden combinarse en la estructura de plugin de Xojo para generar el archivo final .xojo_plugin.

Hemos automatizado todo el proceso de compilación del plugin usando las Acciones de GitHub mediante la creación de flujos de trabajo. Encontrarás su código fuente en la carpeta .github/workflows. Todas las ejecuciones de los flujos de trabajo se encontrarán bajo la pestaña Actions de GitHub (siempre que no se hayan movido o borrado).

LibreSSL

Este flujo de trabajo descargará el código fuente de LibreSSL y lo compilará para todas las plataformas necesarias. Ha de ejecutarse sólo una vez, hasta que exista una nueva versión de LibreSSL que deba incluirse en la próxima compilación del plugin. Es por ello que se trata de un flujo de trabajo que puede ejecutarse manualmente. Este pregunta sobre la versión de LibreSSL que ha de compilarse y si las librerías creadas han de enviarse al repositorio.

CubeSQLPlugin

Este flujo de trabajo creará el Plugin CubeSQL de Xojo para todas las plataformas, utilizando para ello los archivos de la librería LibreSSL del repositorio. Este flujo de trabajo enviará al repositorio los archivos compilados para las librerías resultantes .dll, .dylib y .so.

Crear una Versión

Este flujo de trabajo (Release) es basante obvio, ¿verdad? Se encarga de crear la estructura del archivo final .xojo_plugin, así como una nueva versión en el repositorio con el plugin de Xojo final, listo para su descarga.

Compilar para todas las Plataformas y Arquitecturas

Los dos flujos de trabajo “LibreSSL” y “CubeSQLPlugin” son similares en su enfoque sobre el modo de compilar para todas las plataformas soportadas (Windows, macOs, Linux), así como las arquitecturas (Intel/ARM, 32/64 bits).

GitHub ofrece máquinas virtuales para ejecutar sus flujos de trabajo. La máquina virtual contiene un entorno de herramientas, paquetes, y ajustes disponibles para los flujos de trabajo utilizados por las Acciones de GitHub.

De modo que para nuestros flujos de trabajo sólo has de usar estos entornos. El flujo de trabajo está compuesto por varios pasos, cada uno de los cuales puede ejecutarse por un runner diferente. ¿Recuerdas cuando escribí: “Puedes crear un plugin de Xojo sin involucrar a tu propio equipo”?

En la siguiente captura de pantalla vemos que la parte correspondiente a Linux-ARM64 se crea mediante una máquina Ubuntu 24.04.1 ARM.

macOS

Se ejecuta sobre una máquina virtual macOS de GitHub.
Utiliza las herramientas de línea de comandos preinstalada de Xcode para compilar las partes “Intel x86_64”, “ARM64” y combinarlas en un binario Universal.
CodeSign se utiliza con las credenciales añadidas como secretos en el repositorio.

Linux

ARM32, ARM64

Ejecuta una máquina virtual ARM en GitHub.
Para contar siempre con el mismo toolset de compilación (es decir, para que no importe si GitHub actualiza a una nueva versión de Ubuntu), esta se basa en un contenedor de Docker (por ejemplo arm64v8/gcc) y, de hecho, compila el código fuente en el contendor de Docker.

i386, x86_64

Ejecuta una máquina virtual Linux Intel en GitHub.
También utiliza una imagen Docker gcc para compilar el código fuente.

Windows

Ejecuta una máquina virtual de Windows en GitHub.
Utiliza el entorno de desarrollo Visual Studio preinstalado pa compilar todas las partes correspondientes a “win32”, “x64” y “ARM64”.

Cómo Compilar tu Plugin Xojo

Soy muy consciente de que este artículo no te ayudará a compilar tu propio plugin. Cada uno tiene sus propias idiosincracias y, por tanto, precisa de sus propios pasos y procesos.

Sin embargo, en el caso de que consideres la automatización del proceso de compilación de tus plugin, probablemente te proporcione algunas ideas. Es probable que quieras mirar con más detalle en el código fuente del plugin de código abierto y los flujos de trabajo que permiten compilar CubeSQLPlugin en todas las plataformas y arquitecturas requeridas.

Transicionar de Manual a Automatizado

Al crear un plugin no se tiende a pensar en su proceso de compilación durante las fases iniciales, e incluso tampoco durante la publicación de las primeras versiones.

La creación de un plugin suele ser un proceso manual, en el que se requiere de la ejecución manual de una buena cantidad de pasos y comandos sobre diferentes equipos. Es un proceso tedioso y sujeto a errores. Lleva tiempo, y que se va añadiendo con cada nueva compilación. Existe un momento en el que uno empieza a pensar sobre el modo de agilizar y automatizar el proceso para crear nuevas versiones sin que suponga mucho esfuerzo.

Además siempre es buena idea contar con un entorno de compilación que resulte consistente, más allá de tu propio equipo de desarrollo, dado que puede que instales y cambies cosas que podrían impactar en tus compilaciones. Es por ello por lo que la compilación en un contendor de Docker resulta en un enfoque interesante, dado que permanecerá exactamente igual cada vez, incluso si el equipo que lo aloja ha cambiado (por ejemplo cuando se actualiza la versión del sistema operativo).

¿Cómo puedes transicionar desde un proceso manual a un proceso automatizado para tu propio proyecto? No puedo proporcionar todas las respuestas, pero te daré algunas ideas sobre los posibles pasos involucrados, sin la intención de que puedan resultar completos o la mejor opción para tu proyecto en particular.

Utiliza un sistema de control de versiones
Git y GitHub son gratuitos (prácticamente para todos los casos).
El uso de una solución basada en la nube como copia de seguridad, dado que podría ocurrirle algo a tus equipos.
También puedes beneficiarte del uso de las Acciones de GitHub para los flujos de trabajo, tal y como hemos visto en este artículo.
En primer lugar, cualquier cosa que esté sólo en tu cabeza debería de estar escrita de algún modo. Cuando pase algún tiempo sin que tengas que hacer algo, es probable que olvides el cómo hacerlo o bien alguno de los pasos involucrados.
Empieza documentando todos los pasos, comandos y acciones en una app de anotaciones.
Procura evitar el uso de pasos manuales. ¿Te encuentras copiando y pegando varios comandos en el terminal cada vez?
Ponlo todo en un script del shell, de modo que sólo debas de ejecutar un comando.
Luego podrás utilizar dichos script cuando cambies a un sistema totalmente automatizado.
Cuando finalices con el desarrollo inicial y esté listo para su publicación:
No hagas la publicación desde tu equipo de desarrollo. Puede que esté difunto, roto, lo hayan robado o bien que hayas instalado algún nuevo software que tenga impacto en otros proyectos.
El hecho de contar con un equipo dedicado para las compilaciones es una idea. Sin embargo, tomar el camino de las “Acciones de GitHub” también tiene sus ventajas.
Los “runners” son máquinas virtuales que están aprovisionadas y “frascas” cada vez. Siempre es el mismo entorno para comenzar con una nueva compilación, sin importar lo que hagas durante su proceso.
No precisas mantener varios equipos de compilación tu mismo. Esto permite evitar incluso algunos problemas de seguridad, ya que probablemente no sea tu principal interés mantener todo actualizado. Personalmente prefiero centrarme en la programación y no en el mantenimiento de sistemas.
Sin embargo, puede que los “runners” queden desactualizados en unos cuantos años, y que estén disponibles nuevos runners (con nuevos sistemas operativos).
Por lo general no es un gran problema en macOS y Windows, dado que sus herramientas de compilación suelen ser compatibles hacia atrás durante una gran cantidad de tiempo.
Especialmente en el caso de Linux, hemos decidido no confiar en el host proporcionado sino utilizar una Imagen de Docker y ejecutar los pasos de compilación en el propio contendor de Docker. De esta forma, por ejemplo, puedes utilizar una imagen de Docker que se ajuste perfectamente a tus necesidades de compatibilidad; mientras que el host propiamente dicho puede que sólo tenga (demasiadas) librerías nuevas instaladas.
Empieza poniendo todos tus pasos y scripts en un flujo de trabajo, ya sea en tu propio entorno de compilación dedicado o como Acciones de GitHub.
Utiliza flujos de trabajo ciertamente separados por host (macOS / Windows / Linux).
Divide los scripts largos en partes más pequeñas; por ejemplo: Descarga LibreSSL | Compila x86_64 | Compila arm64 | Compila Universal.
En el caso de que se produzca un error será más fácil ver que “Ha fallado macOS: Build arm64” en comparación con “Ha fallado la compilación macOS” (dado que sería un script más largo).
Ejecutar los flujos de trabajo manualmente está bien, y probablemente sea lo suficientemente bueno.
Una vez que aumente la actividad del proyecto (por ejemplo estés recibiendo una gran cantidad de pull requests o que tengas muchos desarrolladores trabajando en ello).
Asegúrate de que los flujos de trabajo de compilación y de pruebas estén ejecutándose en cada pull request, y requiere que todos ellos se completen correctamente antes de combinarlos. Esto ha sido, de hecho, explicado en el anterior artículo “Xojo Github Actions”.
Resulta doloroso encontrar tras varios commits que la compilación ha dejado de funcionar, teniendo que buscar en el histórico qué podría haberlo causado.
Advertirás que, una vez que todo esté automatizado, no querrás dejar de usarlo.
No introduce un esfuerzo adicional y en vez de ello obtendrás una serie de ventajas (como advertir en las etapas iniciales cuando un cambio en el código provoca problemas en las compilaciones o pruebas).

Un hecho curioso

En el pasado una compilación de CubeSQLPlugin solía llevar un par de horas, y con la atención personal necesaria para asegurarse de que todo funcionase correctamente cada vez.

La primera iteración de los flujos de trabajo redujeron la compilación completa (LibreSSL + plugin) a 25 minutos. Sin requerir de atención o interacciones manuales, lo que significa más tiempo para poder utilizarlo en otras tareas. Lo que tomó la mayor parte del tiempo fue las compilaciones LibreSSL ARM, dado que se realizaban en un hardware Intel con QEMU para la emulación ARM.

Volviendo al inicio de este artículo y la iniciativa Año de Código 2025 de Xojo, en Febrero he mejorado los flujos de trabajo para utilizar los nuevos runner disponibles para Acciones de GitHub, y que funcionan sobre hardware ARM. Esto implica que ya no se requiere la emulación, y que el tiempo de compilación ha bajado ahora a unos 4 minutos para las librerías LibreSSL (requeridas sólo una vez por cada nueva versión de LibreSSL), y 2,5 minutos para el plugin de bases de datos de Xojo para todas las plataformas y arquitecturas requeridas.

¡Eso es todo amigos!

Espero que esta breve introducción sobre cómo puedes beneficiarte de los flujos de trabajo creados con Acciones de GitHub, y Docker, a la hora de compilar un plugin de Xojo, sea de utilidad para unos, y de “alimento para la mente” para otros.