Creación de un flujo de trabajo de CI/CD: implementación automática de un tema de WordPress con acciones de GitHub

Introducción

En el desarrollo web moderno, a menudo hay varios pasos que debe realizar para compilar e implementar su código en producción. Para un tema o complemento de WordPress, eso podría significar instalar dependencias de Composer y/o Node.js, compilar CSS, transpilar JavaScript y cargar archivos en su servidor.

En este artículo, exploraremos cómo puede optimizar su proceso de implementación de WordPress usando GitHub Actions. Crearemos un flujo de trabajo de GitHub Actions para crear e implementar automáticamente un tema de WordPress en su sitio Pressidium WordPress.

Si solo hizo clic en el flujo de trabajo, desplácese hasta la parte inferior de esta publicación y sumérjase de inmediato. Sin embargo, le recomendamos que lea el artículo completo, donde explicamos cómo funciona todo en detalle.

requisitos previos

• Una comprensión básica de Git (creación de un repositorio, confirmación y envío de código, creación de ramas, etc.)
• Familiaridad con la interfaz de GitHub

¿Qué es "implementación" en el desarrollo web?

La implementación en el desarrollo web es el proceso de enviar cambios a un entorno remoto, haciendo que un sitio web o una aplicación estén disponibles para su uso.

A veces usamos el término "implementación" para referirnos a un conjunto de actividades, que incluyen la creación, prueba y transferencia de archivos, mientras que otras veces lo usamos como sinónimo de transferencia de archivos. En este artículo, siempre distinguimos entre compilar e implementar .

Hay muchas maneras de enviar los archivos de su sitio web a un proveedor de alojamiento. En nuestro caso, utilizaremos el Protocolo seguro de transferencia de archivos (SFTP) que, como sugiere su nombre, es un protocolo de red para transferir archivos a través de un canal seguro, como SSH.

¿Qué son las acciones de GitHub?

GitHub Actions es una plataforma de integración continua y entrega continua (CI/CD) que le permite automatizar su proceso de desarrollo e implementación.

En los siguientes párrafos, exploraremos cómo crear un flujo de trabajo de GitHub Actions para crear e implementar un tema de WordPress aprovechando un proveedor de alojamiento que admita entornos de prueba.

La puesta en escena es un entorno de preproducción para pruebas que es casi una réplica exacta de un entorno de producción. Busca reflejar un entorno de producción real lo más fielmente posible, de modo que los cambios se puedan probar allí antes de que se apliquen a un entorno de producción.

Si ya está utilizando Pressidium, los entornos de ensayo se incluyen de forma gratuita en todos los planes. Lea este artículo de KB para obtener más información.

¿Qué es un flujo de trabajo de acciones de GitHub?

Un flujo de trabajo es un proceso automatizado que se desencadena por uno o más eventos y ejecuta uno o más trabajos . Cada trabajo contiene uno o más pasos . Finalmente, cada paso puede ejecutar un script o una acción de GitHub. Un repositorio puede tener múltiples flujos de trabajo, realizando diferentes tareas.

Hay muchos beneficios al usar un flujo de trabajo de GitHub Actions.

• Pasa menos tiempo haciendo trabajo manual, laborioso y repetitivo; más tiempo agregando valor
• Es más fácil mantener la coherencia en todos los entornos aplicando un proceso de implementación específico
• Se integra con su repositorio de GitHub, lo que le permite realizar un seguimiento de los cambios, acceder a los registros de implementación, etc.
• Es reutilizable, lo que significa que puede usar el mismo flujo de trabajo en todos sus repositorios

Empezando

Comencemos con su primer flujo de trabajo creando un nuevo archivo YAML en el .github/workflows/ en su repositorio de GitHub. Comenzaremos con un flujo de trabajo simple para implementar automáticamente en producción, así que llamemos a este archivo deploy.yml .

 # .github/workflows/deploy.yml name: deploy on: push: branches: # Pushing to the `main` branch # will trigger our workflow - main

Usamos la palabra clave on para definir qué eventos pueden desencadenar el flujo de trabajo. En este ejemplo, el flujo de trabajo se ejecutará cuando se realice un envío a la rama main .

Probablemente no necesitemos implementar nada cuando cambien ciertos archivos, como README.md . Podemos usar on.push.paths-ignore para excluir patrones de rutas de archivos.

 name: deploy on: push: branches: - main paths-ignore: - 'bin/**' - 'README.m

Creando tu primer trabajo

Un flujo de trabajo se compone de uno o más trabajos. En este ejemplo, utilizará un solo trabajo de deploy para cargar sus archivos en el entorno de producción de su sitio web.

 name: deploy on: [...] jobs: deploy: runs-on: ubuntu-latest steps: [...]

Cada trabajo se ejecuta en un entorno de ejecución, especificado por runs-on . En el bloque YAML anterior, usamos ubuntu-latest que es una máquina virtual (VM) Ubuntu Linux, alojada en GitHub con la aplicación de ejecución y otras herramientas preinstaladas.

Puede usar un ejecutor alojado en GitHub o hospedar sus propios ejecutores y personalizar el entorno utilizado para ejecutar trabajos. Sin embargo, esto último está fuera del alcance de este artículo.

Revisando tu repositorio de Git

Antes de que pueda hacer algo significativo con su código, debe verificar su repositorio, para que su flujo de trabajo pueda acceder a él. Puede usar la acción de pago para eso.

 jobs: deploy: runs-on: ubuntu-latest steps: - name: Checkout # Checkout our repository under `${GITHUB_WORKSPACE}`, # so our workflow can access it uses: actions/checkout@v3 with: # Fetch the entire Git history fetch-depth: 0

Especificamos una fetch-depth de 0 , lo que dará como resultado la recuperación de todo el historial de Git. Necesitamos esto para cargar solo los archivos que han cambiado en ejecuciones posteriores.

Creación de un usuario SFTP

Para cargar sus archivos a su proveedor de alojamiento, necesitará los detalles de su conexión SFTP (es decir, host, puerto de red y ruta) y un usuario de SFTP.

La mayoría de las veces, puede encontrar estos detalles y crear un usuario SFTP a través del panel de control de su proveedor de alojamiento. Algunos servidores web también le enviarán estos detalles por correo electrónico.

Si ya está utilizando Pressidium, siga estos pasos:

1. Inicie sesión en su panel de Pressidium
2. Seleccione la opción de menú Sitios web en la barra lateral del Panel de control
3. Haga clic en el nombre de su sitio web
4. Navegue a la pestaña SFTP haciendo clic en el enlace en la barra de navegación
5. Tome nota de los detalles de su conexión SFTP
6. Crear un nuevo usuario SFTP

Para crear un nuevo usuario SFTP:

1. Haga clic en Nuevo
2. Seleccione el entorno ( producción o puesta en escena )
3. Proporcione un nombre de usuario y una contraseña (se recomienda una contraseña segura, una combinación de caracteres latinos en minúsculas y mayúsculas, números y caracteres especiales)
4. Mantenga una nota del nombre de usuario y la contraseña que ingresó
5. Haga clic en Crear para crear el usuario.

En el segundo paso, debe elegir el entorno en el que desea realizar la implementación. Para este ejemplo, crearemos un usuario para cada entorno.

Aloje su sitio web con Pressidium

GARANTÍA DE DEVOLUCIÓN DE DINERO DE 60 DÍAS

VER NUESTROS PLANES

Para obtener más información sobre cómo acceder a su sitio Pressidium WordPress a través de SFTP, consulte este artículo de KB.

Almacenamiento de información confidencial

Puede ingresar los detalles de su conexión SFTP y las credenciales de usuario de SFTP directamente en su flujo de trabajo de GitHub Actions. Sin embargo, almacenar información confidencial en su repositorio es una mala idea.

GitHub ofrece secretos cifrados como una forma de almacenar información confidencial en su organización, repositorio o entorno de repositorio.

Para crear un secreto cifrado para un repositorio:

1. Inicie sesión en su cuenta de GitHub
2. Navega a la página principal de tu repositorio
3. Debajo de su nombre de repositorio, haga clic en Configuración
4. Seleccione Secretos y haga clic en Acciones , en la sección Seguridad de la barra lateral
5. Haga clic en el botón Nuevo secreto del repositorio
6. Escriba el nombre del secreto y su valor
7. Haz clic en Agregar secreto

Deberías terminar con una lista de secretos similar a esta:

• SFTP_HOST El nombre de host del servidor SFTP
• SFTP_PORT El puerto del servidor SFTP
• SFTP_USER El nombre de usuario que se usará para la autenticación
• SFTP_PASS La contraseña a utilizar para la autenticación

Carga de archivos a través de SFTP

Para cargar sus archivos a través de SFTP, puede usar⁠, lo adivinó⁠, otra acción de GitHub.

Hay múltiples clientes SFTP y GitHub Actions para elegir. Elegimos nuestro propio lftp-mirror-action , que usa lftp debajo del capó. Una herramienta de transferencia de archivos que admite SFTP y puede transferir varios archivos en paralelo.

 - name: Deploy via SFTP uses: pressidium/lftp-mirror-action@v1 with: host: ${{ secrets.SFTP_HOST }} port: ${{ secrets.SFTP_PORT }} user: ${{ secrets.SFTP_USER }} pass: ${{ secrets.SFTP_PASS }} remoteDir: '/demo-www/wp-content/themes/my-theme' options: '--verbose'

Configurar las entradas de lftp-mirror-action es bastante sencillo:

• Se puede acceder a los detalles de su conexión SFTP y las credenciales de usuario de SFTP a través del contexto de secrets (por ejemplo, ${{ secrets.SFTP_HOST }} )
• El remoteDir es la ruta al directorio de tu tema.
• La opción '--verbose' habilitará la salida detallada, que registrará todas las transferencias de archivos (útil para solucionar problemas)

En Pressidium, las rutas tienen este formato:

• YOUR_INSTALLATION_NAME-www/ como ruta raíz del entorno de producción
• YOUR_INSTALLATION_NAME-dev-www/ como la ruta raíz del entorno de ensayo

donde YOUR_INSTALLATION_NAME es el nombre de su instalación. Tenga en cuenta que el propietario de la cuenta tiene una cuenta SFTP, que se muestra como una cuenta "maestra", que tiene acceso a todos los sitios web, por lo que sus rutas serán diferentes a las anteriores. Se recomienda evitar el uso de esta cuenta y, en su lugar, crear una cuenta separada para cada sitio web al que desee acceder.

Opcionalmente, puede crear un archivo .lftp_ignore en su repositorio, incluidos los patrones de archivo que desea excluir de la implementación.

Aquí hay un ejemplo de cómo podría verse esto:

 ## Directories to ignore .vscode/** .env.** .git/ .github/ ## Files to ignore .gitignore package.json package-lock.json composer.json composer.lock

Poniendolo todo junto

 name: deploy on: push: branches: - main paths-ignore: - 'bin/**' - 'README.md' jobs: deploy: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v3 with: fetch-depth: 0 - name: Deploy via SFTP uses: pressidium/lftp-mirror-action@v1 with: host: ${{ secrets.SFTP_HOST }} port: ${{ secrets.SFTP_PORT }} user: ${{ secrets.SFTP_USER }} pass: ${{ secrets.SFTP_PASS }} remoteDir: '/demo-www/wp-content/themes/my-theme' options: '--verbose'

¡Eso es todo! Su flujo de trabajo ahora puede implementar automáticamente su tema de WordPress.

Creación e implementación de su tema de WordPress

Hasta ahora, mantuvimos las cosas simples enfocándonos solo en implementar sus archivos mientras ignoramos cualquier dependencia que pueda necesitar instalar, compilar scripts que pueda necesitar ejecutar, etc.

Como configuración de ejemplo, usaremos un repositorio de GitHub con dos ramas:

• la rama main estable y lista para la producción, que se implementará en un entorno de producción
• la rama de preview no probada, que sirve como una rama de integración para funciones y se implementará en un entorno de ensayo

Es hora de introducir un trabajo de build y cambiar el nombre de nuestro flujo de trabajo a build-deploy , ya que será responsable de compilar e implementar nuestro código.

 name: build-deploy on: push: branches: - main paths-ignore: - 'bin/**' - 'README.md' jobs: build: runs-on: ubuntu-latest steps: [...] deploy: [...]

Revisando tu repositorio de Git

Cada trabajo se ejecuta en una instancia nueva de una imagen de corredor, por lo que debe verificar su repositorio de GitHub una vez más en el trabajo de build .

 build: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v3

No es necesario que obtenga todo el historial de Git en el trabajo de compilación, por lo que puede ceñirse a los valores predeterminados para las entradas de la acción.

Instalación de dependencias

Algunos temas utilizan paquetes y bibliotecas de terceros. Si su tema requiere paquetes de PHP y/o JavaScript, puede usar un administrador de paquetes, como Composer, npm o yarn.

Por el bien de este ejemplo, supondremos que necesita instalar las dependencias Composer y Node.js. Afortunadamente para nosotros, existen acciones listas para usar para eso.

 steps: - name: Checkout uses: actions/checkout@v3 - name: Install Composer dependencies uses: php-actions/composer@v6 - name: Install Node.js LTS uses: actions/setup-node@v3 with: node-version: 'lts/*' cache: 'yarn' - name: Install Node.js dependencies run: yarn install

La acción del compositor ejecutará la composer install del compositor de forma predeterminada, por lo que no tiene que configurar ninguno de sus parámetros de entrada.

Para la acción de configuración del nodo , establecemos valores personalizados para la node-version y las entradas de cache para especificar que queremos:

• obtenga la versión de soporte a largo plazo (o LTS) de Node.js
• almacena en caché las dependencias obtenidas a través del administrador de paquetes de hilo

Luego, el siguiente paso ejecutará yarn install para instalar las dependencias de Node.js. Recuerde, un paso puede ejecutar un script o una acción de GitHub.

Tenga en cuenta que el almacenamiento en caché puede acelerar significativamente su flujo de trabajo. La descarga de dependencias cada vez que se ejecuta su flujo de trabajo dará como resultado un tiempo de ejecución más largo. Puede almacenar en caché las dependencias de un trabajo mediante la acción de caché (que es lo que también hace la acción setup-node bajo el capó), lo que acelera el tiempo necesario para volver a crear archivos.

Ejecutando su proceso de compilación

Una vez más, supondremos que necesita ejecutar un proceso de "compilación": es posible que necesite ejecutar un preprocesador para compilar sus hojas de estilo, transpilar sus scripts ES6+, etc. Eso generalmente significa que ha definido un script de build en su archivo package.json .

Por lo tanto, necesitará otro paso para ejecutar ese proceso de compilación.

 - name: Build theme run: yarn run build

Si necesita ejecutar un script diferente para las ramas main y de preview (por ejemplo, build para la rama main y staging para la preview ), puede hacerlo así:

 - name: Build theme run: | if [[ "${{ github.base_ref }}" == "main" || "${{ github.ref }}" == "refs/heads/main" ]]; then yarn run build else yarn run staging fi

Por último, dado que cada trabajo se ejecuta en una instancia nueva de una imagen de corredor, los trabajos en su flujo de trabajo están completamente aislados. Eso significa que necesita una forma de almacenar temporalmente los archivos que acaba de crear, para que el trabajo de deploy pueda acceder a ellos. Introduzca artefactos .

Artefactos

Los artefactos le permiten conservar los datos después de que se completa un trabajo, para que pueda compartir datos entre trabajos en un flujo de trabajo.

Introduzcamos un paso adicional en su trabajo de build para conservar los datos producidos durante los pasos de compilación con un período de retención de 1 día, mediante la acción Cargar artefacto . Asumiremos que Composer instala sus dependencias en el directorio vendor/ , y nuestro script de build exporta archivos al directorio dist/ .

 - name: Upload artifact uses: actions/upload-artifact@v3 with: name: my-theme-build path: | dist/ vendor/ retention-days: 1

Dependiendo del tamaño de su repositorio y de la frecuencia con la que realice envíos, es posible que desee echar un vistazo a los límites de uso, la facturación y la administración de GitHub.

En el momento de escribir este artículo, de forma predeterminada, GitHub almacena registros de compilación y artefactos durante 90 días y proporciona 500 MB de almacenamiento en el plan "GitHub Free".

Ejecutar trabajos secuencialmente

Un flujo de trabajo se compone de uno o más trabajos, que se ejecutan en paralelo de forma predeterminada. En nuestro caso, tenemos que construir nuestro tema antes de poder implementarlo. Para ejecutar sus trabajos de build e deploy secuencialmente , debe definir una dependencia mediante la palabra clave jobs.<job_id>.needs .

 deploy: runs-on: ubuntu-latest needs: build

En el siguiente ejemplo, indicamos que el trabajo de build debe completarse correctamente antes de que se pueda ejecutar el trabajo de deploy .

 name: build-deploy on: [...] jobs: build: runs-on: ubuntu-latest steps: [...] deploy: runs-on: ubuntu-latest needs: build steps: [...]

Descargando el artefacto

Antes de que pueda cargar los datos creados durante los pasos de compilación, debe descargarlos. Revisemos el trabajo de deploy e introduzcamos un paso adicional.

 - name: Download artifact uses: actions/download-artifact@v3 with: name: my-theme-build path: .

Puede usar la acción de hecho Descargar -Artifact de manera similar a Upload-Artifact . Asegúrese de especificar el mismo nombre my-theme-build , en este caso, para ambas acciones.

Poniendolo todo junto

 name: build-deploy on: push: branches: - main paths-ignore: - 'bin/**' - 'README.md' jobs: build: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v3 - name: Install Composer dependencies uses: php-actions/composer@v6 - name: Install Node.js LTS uses: actions/setup-node@v3 with: node-version: 'lts/*' cache: 'yarn' - name: Install Node.js dependencies run: yarn install - name: Build theme run: | if [[ "${{ github.base_ref }}" == "main" || "${{ github.ref }}" == "refs/heads/main" ]]; then yarn run build else yarn run staging fi - name: Upload artifact uses: actions/upload-artifact@v3 with: name: my-theme-build path: | dist/ vendor/ retention-days: 1 deploy: runs-on: ubuntu-latest needs: build steps: - name: Checkout uses: actions/checkout@v3 with: fetch-depth: 0 - name: Download artifact uses: actions/download-artifact@v3 with: name: my-theme-build path: . - name: Deploy via SFTP uses: pressidium/lftp-mirror-action@v1 with: host: ${{ secrets.SFTP_HOST }} port: ${{ secrets.SFTP_PORT }} user: ${{ secrets.SFTP_USER }} pass: ${{ secrets.SFTP_PASS }} remoteDir: '/demo-www/wp-content/themes/my-theme' options: '--verbose'

¡Ahora tiene un flujo de trabajo de GitHub Actions que puede compilar e implementar automáticamente su código en producción cuando empuja a la rama main ! Sin embargo, al comienzo de este artículo, describimos un flujo de trabajo que podría implementarse tanto en entornos de producción como de ensayo, según la rama a la que esté presionando. Si todavía estás dispuesto a hacerlo, ¡sigue leyendo!

Implementación de su tema en múltiples entornos

La implementación en múltiples entornos puede requerir cambiar un poco su flujo de trabajo. Por ejemplo, a menudo se recomienda tener usuarios SFTP separados para cada entorno y se considera una mejor práctica. En Pressidium, los usuarios de SFTP son diferentes para los entornos de producción y preparación de un sitio web.

Entonces, creemos diferentes secretos para el nombre de usuario/contraseña de cada usuario. Eso significa que nuestra lista actualizada de secretos encriptados debería verse así:

• SFTP_HOST
• SFTP_PORT
• SFTP_PROD_USER
• SFTP_PROD_PASS
• SFTP_STAG_USER
• SFTP_STAG_PASS

Es posible que también deba actualizar el host y el puerto de red. Aunque, en este caso, no hay necesidad de cambiarlos, ya que son idénticos para ambos entornos.

Configuración de variables de entorno

Una variable de entorno es una variable formada por un par nombre/valor y forma parte del entorno en el que se ejecuta un proceso.

En un flujo de trabajo de GitHub Actions, puede usar la palabra clave env para establecer una variable de entorno personalizada que tenga como alcance:

• Todo el flujo de trabajo, mediante el uso de env en el nivel superior del flujo de trabajo
• Un trabajo dentro de un flujo de trabajo, usando env al nivel de ese trabajo
• Un paso específico dentro de un trabajo, usando env al nivel de ese paso

También puede agregar variables de entorno a $GITHUB_ENV , lo que hace que esa variable esté disponible para cualquier paso posterior en un trabajo de flujo de trabajo.

Como puede ver, hay varias formas de crear sus flujos de trabajo. Por lo tanto, siéntase libre de usar el que tenga más sentido para usted.

En nuestro caso, configuramos variables de entorno dentro de un paso de un trabajo para almacenar valores temporalmente y acceder a ellos desde otro paso que se ejecuta más adelante en nuestro flujo de trabajo. push variables de entorno a $GITHUB_ENV dentro de los pasos que se ejecutan para eventos de envío a ramas específicas para mostrar cómo puede establecer condicionalmente sus variables personalizadas.

 - name: Set environment variables (main) if: github.ref == 'refs/heads/main' run: | echo "SFTP_USER=${{ secrets.SFTP_PROD_USER }}" >> $GITHUB_ENV echo "SFTP_PASS=${{ secrets.SFTP_PROD_PASS }}" >> $GITHUB_ENV echo "DEPLOY_PATH=/demo-www/wp-content/themes/my-theme" >> $GITHUB_ENV - name: Set environment variables (preview) if: github.ref == 'refs/heads/preview' run: | echo "SFTP_USER=${{ secrets.SFTP_STAG_USER }}" >> $GITHUB_ENV echo "SFTP_PASS=${{ secrets.SFTP_STAG_PASS }}" >> $GITHUB_ENV echo "DEPLOY_PATH=/demo-dev-www/wp-content/themes/my-theme" >> $GITHUB_ENV

Usamos la palabra clave if para limitar cada paso a una rama específica. De esa manera, Establecer variables de entorno (principal) se ejecutará solo si los cambios se enviaron a la rama main .

El $DEPLOY_PATH también puede diferir para cada entorno.

Por ejemplo, en Pressidium:

• Las rutas para entornos de producción siguen el formato /<WEBSITE_NAME>-www/
• Las rutas para los entornos de prueba siguen el formato /<WEBSITE_NAME>-dev-www/

Configuración de salidas

Nos gustaría usar las variables de entorno que acabamos de configurar como entradas para la acción de GitHub que va a transferir archivos a través de SFTP.

Desafortunadamente, por el momento, no parece posible hacer referencia a las variables de entorno como entradas de una acción de GitHub. Puede evitarlo creando un paso adicional que generará los valores que necesitará usar como entradas más adelante.

 - name: Set outputs # Workaround to reference environment variables as inputs # using step outputs, since we can't pass environment # variables as inputs at the moment. id: sftp_details run: | echo "user=${SFTP_USER}" >> $GITHUB_OUTPUT echo "pass=${SFTP_PASS}" >> $GITHUB_OUTPUT echo "deploy_path=${DEPLOY_PATH}" >> $GITHUB_OUTPUT

Ahora tiene salidas user , pass y deploy_path para el paso sftp_details , que puede usar para hacer referencia a estos valores como las entradas de su próximo paso.

Subir archivos a diferentes entornos

Cargar archivos a través de SFTP es más o menos lo mismo que antes, pero en lugar de hacer referencia al contexto de los secrets y codificar remoteDir , usará los resultados del paso anterior.

 - name: Deploy via SFTP uses: pressidium/lftp-mirror-action@v1 with: host: ${{ secrets.SFTP_HOST }} port: ${{ secrets.SFTP_PORT }} user: ${{ steps.sftp_details.outputs.user }} pass: ${{ steps.sftp_details.outputs.pass }} remoteDir: ${{ steps.sftp_details.outputs.deploy_path }} options: '--verbose'

Use ${{ steps.<step_id>.outputs.<output_name> }} para acceder a la salida de un paso. Por ejemplo, ${{ steps.sftp_details.outputs.user }} para acceder a la salida del user del paso sftp_details .

¡Uf, finalmente! Su flujo de trabajo ahora puede crear e implementar su tema de WordPress tanto en su entorno de producción como de ensayo.

Uniendo el flujo de trabajo completo

 name: build-deploy on: push: branches: # Pushing to any of the following # branches will trigger our workflow - main - preview paths-ignore: # When all the path names match patterns in `paths-ignore` # the workflow will not run. We don't want to do anything # if we have changed *only* (some of) these files - 'bin/**' - 'README.md' jobs: build: runs-on: ubuntu-latest steps: - name: Checkout # Checkout our repository under `${GITHUB_WORKSPACE}`, # so our workflow can access it uses: actions/checkout@v3 - name: Install Composer dependencies # This will run `composer install` # since that's its default command uses: php-actions/composer@v6 - name: Install Node.js LTS # We use the LTS version of Node.js # and cache packages installed via yarn uses: actions/setup-node@v3 with: node-version: 'lts/*' cache: 'yarn' - name: Install Node.js dependencies run: yarn install - name: Build theme # Run the `build` script for production, # and the `staging` script for staging run: | if [[ "${{ github.base_ref }}" == "main" || "${{ github.ref }}" == "refs/heads/main" ]]; then yarn run build else yarn run staging fi - name: Upload artifact # Persist data produced during the build steps # with a retention period of 1 day uses: actions/upload-artifact@v3 with: name: my-theme-build path: | dist/ vendor/ retention-days: 1 deploy: runs-on: ubuntu-latest needs: build steps: - name: Checkout uses: actions/checkout@v3 with: # Fetch the entire Git history fetch-depth: 0 - name: Download artifact uses: actions/download-artifact@v3 with: name: my-theme-build path: . - name: Set environment variables (main) if: github.ref == 'refs/heads/main' run: | echo "SFTP_USER=${{ secrets.SFTP_PROD_USER }}" >> $GITHUB_ENV echo "SFTP_PASS=${{ secrets.SFTP_PROD_PASS }}" >> $GITHUB_ENV echo "DEPLOY_PATH=/demo-www/wp-content/themes/my-theme" >> $GITHUB_ENV - name: Set environment variables (preview) if: github.ref == 'refs/heads/preview' run: | echo "SFTP_USER=${{ secrets.SFTP_STAG_USER }}" >> $GITHUB_ENV echo "SFTP_PASS=${{ secrets.SFTP_STAG_PASS }}" >> $GITHUB_ENV echo "DEPLOY_PATH=/demo-dev-www/wp-content/themes/my-theme" >> $GITHUB_ENV - name: Set outputs # Workaround to reference environment variables as inputs # using step outputs, since we can't pass environment # variables as inputs at the moment. id: sftp_details run: | echo "user=${SFTP_USER}" >> $GITHUB_OUTPUT echo "pass=${SFTP_PASS}" >> $GITHUB_OUTPUT echo "deploy_path=${DEPLOY_PATH}" >> $GITHUB_OUTPUT - name: Deploy via SFTP uses: pressidium/lftp-mirror-action@v1 with: host: ${{ secrets.SFTP_HOST }} port: ${{ secrets.SFTP_PORT }} user: ${{ steps.sftp_details.outputs.user }} pass: ${{ steps.sftp_details.outputs.pass }} remoteDir: ${{ steps.sftp_details.outputs.deploy_path }} options: '--verbose'

También puede encontrar un tema de WordPress de ejemplo y un flujo de trabajo de GitHub Actions en este repositorio de GitHub.

Conclusión

¡Ahí tienes! GitHub Actions es una herramienta poderosa que facilita la automatización de la creación e implementación de sus temas y complementos de WordPress.

Apenas hemos arañado la superficie de lo que puede lograr con GitHub Actions. Sus próximos pasos podrían ser ejecutar automáticamente cualquier prueba que pueda tener, abrir problemas o notificar en Slack cuando se realiza una implementación, y la lista continúa.

Eche un vistazo a GitHub Marketplace donde, en el momento de escribir este artículo, puede encontrar más de 15 000 acciones para usar en sus flujos de trabajo de GitHub Actions.

¿Entonces, Qué esperas?

• Eche un vistazo al flujo de trabajo de este repositorio en GitHub
• Cree un nuevo archivo YAML en .github/workflows/ en su repositorio de Git
• Disfrute de compilaciones e implementaciones automatizadas

¡Felices implementaciones!