Construire un flux de travail CI/CD - Déploiement automatique d'un thème WordPress avec des actions GitHub

Introduction

Dans le développement Web moderne, vous devez souvent effectuer plusieurs étapes pour créer et déployer votre code en production. Pour un thème ou un plugin WordPress, cela peut signifier installer des dépendances Composer et/ou Node.js, compiler CSS, transpiler JavaScript et télécharger des fichiers sur votre serveur.

Dans cet article, nous allons explorer comment vous pouvez rationaliser votre processus de déploiement WordPress à l'aide de GitHub Actions. Nous allons créer un flux de travail GitHub Actions pour créer et déployer automatiquement un thème WordPress sur votre site Pressidium WordPress.

Si vous n'avez cliqué que pour le flux de travail, faites défiler vers le bas de cet article et plongez tout de suite. Cependant, nous vous encourageons à lire l'intégralité de l'article, où nous expliquons comment tout fonctionne en détail !

Conditions préalables

• Une compréhension de base de Git (création d'un référentiel, validation et envoi de code, création de branches, etc.)
• Familiarité avec l'interface de GitHub

Qu'est-ce que le « déploiement » dans le développement Web ?

Le déploiement dans le développement Web est le processus consistant à appliquer des modifications à un environnement distant, rendant un site Web ou une application disponible pour utilisation.

Parfois, nous utilisons le terme « déploiement » pour désigner un ensemble d'activités, qui incluent la création, le test et le transfert de fichiers, tandis que d'autres fois, nous l'utilisons comme synonyme de transfert de fichiers. Dans cet article, nous faisons toujours la distinction entre la création et le déploiement de .

Il existe de nombreuses façons de transférer les fichiers de votre site Web vers un fournisseur d'hébergement. Dans notre cas, nous utiliserons le protocole SFTP (Secure File Transfer Protocol) qui, comme son nom l'indique, est un protocole réseau permettant de transférer des fichiers via un canal sécurisé, tel que SSH.

Qu'est-ce que GitHub Actions ?

GitHub Actions est une plateforme d'intégration continue et de livraison continue (CI/CD) qui vous permet d'automatiser votre pipeline de construction et de déploiement.

Dans les paragraphes suivants, nous allons explorer comment créer un flux de travail GitHub Actions pour créer et déployer un thème WordPress en exploitant un fournisseur d'hébergement qui prend en charge les environnements de staging.

La mise en scène est un environnement de pré-production pour les tests qui est presque une réplique exacte d'un environnement de production. Il cherche à refléter le plus fidèlement possible un environnement de production réel, afin que les modifications puissent y être testées avant d'être appliquées à un environnement de production.

Si vous utilisez déjà Pressidium, les environnements de mise en scène sont inclus gratuitement dans tous les plans. Lisez cet article de la base de connaissances pour plus d'informations.

Qu'est-ce qu'un workflow GitHub Actions ?

Un workflow est un processus automatisé qui est déclenché par un ou plusieurs événements et exécute une ou plusieurs tâches . Chaque travail contient une ou plusieurs étapes . Enfin, chaque étape peut soit exécuter un script, soit une action GitHub. Un référentiel peut avoir plusieurs workflows, exécutant différentes tâches.

L'utilisation d'un workflow GitHub Actions présente de nombreux avantages.

• Vous passez moins de temps à effectuer des tâches manuelles, laborieuses et répétitives ; plus de temps à ajouter de la valeur
• Il est plus facile d'être cohérent entre les environnements en appliquant un processus de déploiement spécifique
• Il s'intègre à votre référentiel GitHub, vous permettant de suivre les modifications, d'accéder aux journaux de déploiement, etc.
• Il est réutilisable, ce qui signifie que vous pouvez utiliser le même flux de travail dans tous vos référentiels

Commencer

Commençons avec votre tout premier workflow en créant un nouveau fichier YAML dans le .github/workflows/ de votre référentiel GitHub. Nous allons commencer par un workflow simple à déployer automatiquement en production, nommons donc ce fichier deploy.yml .

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

Nous utilisons on mot-clé on pour définir quels événements peuvent déclencher le workflow. Dans cet exemple, le workflow s'exécutera lorsqu'un push est effectué vers la branche main .

Nous n'avons probablement pas besoin de déployer du tout lorsque certains fichiers changent, comme README.md . Nous pouvons utiliser on.push.paths-ignore pour exclure les modèles de chemin de fichier.

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

Création de votre premier emploi

Un flux de travail est composé d'un ou plusieurs travaux. Dans cet exemple, vous utiliserez une seule tâche de deploy pour télécharger vos fichiers dans l'environnement de production de votre site Web.

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

Chaque travail s'exécute dans un environnement d'exécution, spécifié par runs-on . Dans le bloc YAML ci-dessus, nous utilisons ubuntu-latest qui est une machine virtuelle (VM) Ubuntu Linux, hébergée par GitHub avec l'application runner et d'autres outils préinstallés.

Vous pouvez soit utiliser un runner hébergé sur GitHub, soit héberger vos propres runners et personnaliser l'environnement utilisé pour exécuter les tâches. Cependant, ce dernier sort du cadre de cet article.

Vérification de votre référentiel Git

Avant de pouvoir faire quoi que ce soit de significatif avec votre code, vous devez consulter votre référentiel, afin que votre flux de travail puisse y accéder. Vous pouvez utiliser l'action de paiement pour cela.

 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

Nous spécifions une fetch-depth de 0 , ce qui entraînera la récupération de l'intégralité de l'historique Git. Nous en avons besoin pour télécharger uniquement les fichiers qui ont été modifiés lors des exécutions suivantes.

Créer un utilisateur SFTP

Pour télécharger vos fichiers sur votre fournisseur d'hébergement, vous aurez besoin de vos informations de connexion SFTP (c'est-à-dire hôte, port réseau et chemin) et d'un utilisateur SFTP.

La plupart du temps, vous pouvez trouver ces détails et créer un utilisateur SFTP via le tableau de bord de votre hébergeur. Certains hébergeurs Web vous enverront également ces informations par e-mail.

Si vous utilisez déjà Pressidium, suivez ces étapes :

1. Connectez-vous à votre tableau de bord Pressidium
2. Sélectionnez l'option de menu Sites Web dans la barre latérale du tableau de bord
3. Cliquez sur le nom de votre site
4. Accédez à l'onglet SFTP en cliquant sur le lien dans la barre de navigation
5. Gardez une note de vos détails de connexion SFTP
6. Créer un nouvel utilisateur SFTP

Pour créer un nouvel utilisateur SFTP :

1. Cliquez sur Nouveau
2. Sélectionnez l' environnement ( production ou mise en scène )
3. Fournissez un nom d' utilisateur et un mot de passe (un mot de passe fort, un mélange de caractères latins minuscules et majuscules, de chiffres et de caractères spéciaux est recommandé)
4. Notez le nom d'utilisateur et le mot de passe que vous avez saisis
5. Cliquez sur Créer pour créer l'utilisateur

À la deuxième étape, vous devez choisir l'environnement dans lequel vous souhaitez déployer. Pour cet exemple, nous allons créer un utilisateur pour chaque environnement.

Hébergez votre site web avec Pressidium

GARANTIE DE REMBOURSEMENT DE 60 JOURS

VOIR NOS FORFAITS

Pour plus d'informations sur l'accès à votre site WordPress Pressidium via SFTP, reportez-vous à cet article de la base de connaissances.

Stockage d'informations sensibles

Vous pouvez entrer vos détails de connexion SFTP et vos informations d'identification d'utilisateur SFTP directement dans votre flux de travail GitHub Actions. Cependant, stocker des informations sensibles dans votre référentiel est une mauvaise idée.

GitHub offre des secrets chiffrés comme moyen de stocker des informations sensibles dans votre organisation, référentiel ou environnement de référentiel.

Pour créer un secret chiffré pour un dépôt :

1. Connectez-vous à votre compte GitHub
2. Accédez à la page principale de votre référentiel
3. Sous le nom de votre référentiel, cliquez sur Paramètres
4. Sélectionnez Secrets et cliquez sur Actions , sous la section Sécurité de la barre latérale
5. Cliquez sur le bouton Nouveau secret de dépôt
6. Tapez le nom du secret et sa valeur
7. Cliquez sur Ajouter un secret

Vous devriez vous retrouver avec une liste de secrets similaire à celle-ci :

• SFTP_HOST Le nom d'hôte du serveur SFTP
• SFTP_PORT Le port du serveur SFTP
• SFTP_USER Le nom d'utilisateur à utiliser pour l'authentification
• SFTP_PASS Le mot de passe à utiliser pour l'authentification

Téléchargement de fichiers via SFTP

Pour télécharger vos fichiers via SFTP, vous pouvez utiliser⁠—vous l'avez deviné⁠—une autre action GitHub.

Il existe plusieurs clients SFTP et actions GitHub parmi lesquels choisir. Nous sommes allés avec notre propre lftp-mirror-action , qui utilise lftp sous le capot. Un outil de transfert de fichiers qui prend en charge SFTP et peut transférer plusieurs fichiers en parallèle.

 - 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'

La configuration des entrées de l' action lftp-mirror est assez simple :

• Les détails de votre connexion SFTP et les informations d'identification de l'utilisateur SFTP sont accessibles via le contexte des secrets (par exemple, ${{ secrets.SFTP_HOST }} )
• Le remoteDir est le chemin vers le répertoire de votre thème
• L'option '--verbose' sortie détaillée, qui enregistrera tous les transferts de fichiers (utile pour le dépannage)

Sur Pressidium, les chemins sont formatés comme ceci :

• YOUR_INSTALLATION_NAME-www/ comme chemin racine de l'environnement de production
• YOUR_INSTALLATION_NAME-dev-www/ comme chemin racine de l'environnement de staging

où YOUR_INSTALLATION_NAME est le nom de votre installation. Notez que le propriétaire du compte a un compte SFTP, affiché en tant que compte "maître", qui a accès à tous les sites Web, de sorte que leurs chemins seront différents de ceux ci-dessus. Il est recommandé d'éviter d'utiliser ce compte et de créer plutôt un compte distinct pour chaque site Web auquel vous souhaitez accéder.

Vous pouvez éventuellement créer un fichier .lftp_ignore dans votre référentiel, y compris tous les modèles de fichiers que vous souhaitez exclure du déploiement.

Voici un exemple de ce à quoi cela pourrait ressembler :

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

Mettre tous ensemble

 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'

C'est ça! Votre workflow peut désormais déployer automatiquement votre thème WordPress.

Construire et déployer votre thème WordPress

Jusqu'à présent, nous avons simplifié les choses en nous concentrant uniquement sur le déploiement de vos fichiers tout en ignorant les dépendances que vous pourriez avoir besoin d'installer, de créer des scripts que vous pourriez avoir besoin d'exécuter, etc.

Comme exemple de configuration, nous utiliserons un dépôt GitHub avec deux branches :

• la branche main stable et prête pour la production, qui sera déployée dans un environnement de production
• la branche de preview non testée, qui sert de branche d'intégration pour les fonctionnalités et sera déployée dans un environnement intermédiaire

Il est temps d'introduire une tâche de build et de renommer notre flux de travail en build-deploy , car il sera responsable de la construction et du déploiement de notre code.

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

Vérification de votre référentiel Git

Chaque travail s'exécute dans une nouvelle instance d'une image de coureur, vous devez donc vérifier à nouveau votre référentiel GitHub dans le travail de build .

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

Vous n'avez pas besoin de récupérer l'intégralité de l'historique Git dans la tâche de build, vous pouvez donc vous en tenir aux valeurs par défaut pour les entrées de l'action.

Installation des dépendances

Certains thèmes utilisent des packages et des bibliothèques tiers. Si votre thème nécessite des packages PHP et/ou JavaScript, vous pouvez utiliser un gestionnaire de packages, comme Composer, npm ou yarn.

Pour les besoins de cet exemple, nous supposerons que vous devez installer les dépendances Composer et Node.js. Heureusement pour nous, il existe des actions prêtes à l'emploi pour cela.

 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

L'action composer exécutera composer install par défaut, vous n'avez donc pas à configurer l'un de ses paramètres d'entrée.

Pour l'action setup-node , nous définissons des valeurs personnalisées pour les entrées node-version et cache afin de spécifier que nous voulons :

• obtenir la version de support à long terme (ou LTS) de Node.js
• cache toutes les dépendances récupérées via le gestionnaire de paquets de fils

Ensuite, l'étape suivante exécutera yarn install pour installer les dépendances Node.js. N'oubliez pas qu'une étape peut exécuter un script ou une action GitHub.

Notez que la mise en cache peut considérablement accélérer votre flux de travail. Le téléchargement des dépendances à chaque exécution de votre flux de travail entraînera une durée d'exécution plus longue. Vous pouvez mettre en cache les dépendances d'un travail à l'aide de l'action cache (ce que fait également l'action setup-node sous le capot), ce qui accélère le temps nécessaire à la recréation des fichiers.

Exécution de votre processus de construction

Encore une fois, nous supposerons que vous devez exécuter un processus de "construction" - vous devrez peut-être exécuter un préprocesseur pour compiler vos feuilles de style, transpiler vos scripts ES6+, etc. Cela signifie généralement que vous avez défini un script de build dans votre fichier package.json .

Donc, vous aurez besoin d'une autre étape pour exécuter ce processus de construction.

 - name: Build theme run: yarn run build

Si vous avez besoin d'exécuter un script différent pour les branches main et preview (par exemple, build pour la branche main et staging pour preview ), vous pouvez le faire comme suit :

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

Enfin, étant donné que chaque tâche s'exécute dans une nouvelle instance d'une image d'exécution, les tâches de votre flux de travail sont complètement isolées. Cela signifie que vous avez besoin d'un moyen de stocker temporairement les fichiers que vous venez de créer, afin qu'ils soient accessibles par la tâche de deploy . Entrez les artefacts .

Artefacts

Les artefacts vous permettent de conserver les données après la fin d'une tâche, afin que vous puissiez partager des données entre les tâches d'un flux de travail.

Introduisons une étape supplémentaire dans votre tâche de build pour conserver les données produites pendant les étapes de build avec une période de rétention de 1 jour, à l'aide de l'action Upload-Artifact . Nous supposerons que Composer installe ses dépendances dans le répertoire vendor/ et que notre script de build exporte les fichiers dans le répertoire dist/ .

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

En fonction de la taille de votre référentiel et de la fréquence à laquelle vous poussez, vous voudrez peut-être jeter un œil aux limites d'utilisation, à la facturation et à l'administration de GitHub.

Au moment de la rédaction, par défaut, GitHub stocke les journaux de construction et les artefacts pendant 90 jours et fournit 500 Mo de stockage sur le plan "GitHub Free".

Exécuter des tâches de manière séquentielle

Un workflow est composé d'un ou plusieurs travaux, qui s'exécutent en parallèle par défaut. Dans notre cas, nous devons construire notre thème avant de pouvoir le déployer. Pour exécuter vos tâches de build et de deploy de manière séquentielle , vous devez définir une dépendance à l'aide du mot-clé jobs.<job_id>.needs .

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

Dans l'exemple ci-dessous, nous indiquons que la tâche de build doit se terminer avec succès avant que la tâche de deploy puisse s'exécuter.

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

Téléchargement de l'artefact

Avant de pouvoir télécharger des données créées au cours des étapes de génération, vous devez les télécharger. Reprenons la tâche de deploy et introduisons une étape supplémentaire.

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

Vous pouvez utiliser l'action de fait Download -Arti de la même manière que Upload-Artifact . Assurez-vous que vous spécifiez le même nom ― my-theme-build , dans ce cas ― pour les deux actions.

Mettre tous ensemble

 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'

Vous disposez maintenant d'un flux de travail GitHub Actions qui peut automatiquement créer et déployer votre code en production lorsque vous poussez vers la branche main ! Cependant, au début de cet article, nous avons décrit un flux de travail qui pourrait être déployé à la fois dans des environnements de production et de staging, selon la branche vers laquelle vous poussez. Si vous êtes toujours partant, continuez à lire!

Déploiement de votre thème dans plusieurs environnements

Le déploiement dans plusieurs environnements peut nécessiter de modifier légèrement votre flux de travail. Par exemple, avoir des utilisateurs SFTP distincts pour chaque environnement est souvent recommandé et considéré comme une bonne pratique. Dans Pressidium, les utilisateurs SFTP sont différents pour les environnements de production et de mise en scène d'un site Web.

Alors, créons différents secrets pour le nom d'utilisateur/mot de passe de chaque utilisateur. Cela signifie que notre liste mise à jour des secrets chiffrés devrait ressembler à ceci :

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

Vous devrez peut-être également mettre à jour l'hôte et le port réseau. Cependant, dans ce cas, il n'est pas nécessaire de les modifier, car ils sont identiques pour les deux environnements.

Définition des variables d'environnement

Une variable d'environnement est une variable composée d'une paire nom/valeur et fait partie de l'environnement dans lequel un processus s'exécute.

Dans un workflow GitHub Actions, vous pouvez utiliser le mot-clé env pour définir une variable d'environnement personnalisée dont la portée est :

• L'ensemble du flux de travail, en utilisant env au niveau supérieur du flux de travail
• Un travail dans un flux de travail, en utilisant env au niveau de ce travail
• Une étape spécifique dans un travail, en utilisant env au niveau de cette étape

Vous pouvez également ajouter des variables d'environnement à $GITHUB_ENV , ce qui rend cette variable disponible pour toutes les étapes suivantes d'un travail de workflow.

Comme vous pouvez le constater, il existe plusieurs façons de créer vos flux de travail. Alors, n'hésitez pas à utiliser celui qui vous convient le mieux.

Dans notre cas, nous définissons des variables d'environnement dans une étape d'un travail pour stocker temporairement des valeurs et y accéder à partir d'une autre étape qui s'exécute plus tard dans notre flux de travail. Nous ajouterons des variables d'environnement à $GITHUB_ENV dans les étapes qui s'exécutent pour les événements push vers des branches spécifiques pour montrer comment vous pouvez définir de manière conditionnelle vos variables personnalisées.

 - 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

Nous utilisons le mot-clé if pour limiter chaque étape à une branche spécifique. De cette façon, Définir les variables d'environnement (main) ne s'exécutera que si les modifications ont été transmises à la branche main .

Le $DEPLOY_PATH peut également différer pour chaque environnement.

Par exemple, sur Pressidium :

• Les chemins pour les environnements de production suivent le format /<WEBSITE_NAME>-www/
• Les chemins d'accès aux environnements de staging suivent le /<WEBSITE_NAME>-dev-www/

Réglage des sorties

Nous aimerions utiliser les variables d'environnement que nous venons de définir comme entrées de l'action GitHub qui va transférer des fichiers via SFTP.

Malheureusement, pour le moment, il ne semble pas possible de référencer des variables d'environnement en tant qu'entrées d'une action GitHub. Vous pouvez contourner ce problème en créant une étape supplémentaire qui générera les valeurs que vous devrez utiliser ultérieurement comme entrées.

 - 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

Vous avez maintenant les sorties user , pass et deploy_path pour l'étape sftp_details , que vous pouvez utiliser pour référencer ces valeurs comme entrées de votre prochaine étape.

Téléchargement de fichiers dans différents environnements

Le téléchargement de fichiers via SFTP est à peu près le même qu'avant, mais au lieu de référencer le contexte des secrets et de coder en dur le remoteDir , vous utiliserez les sorties de l'étape précédente.

 - 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'

Utilisez ${{ steps.<step_id>.outputs.<output_name> }} pour accéder à la sortie d'une étape. Par exemple, ${{ steps.sftp_details.outputs.user }} pour accéder à la sortie user de l'étape sftp_details .

Ouf, enfin ! Votre flux de travail peut désormais créer et déployer votre thème WordPress dans vos environnements de production et de staging.

Assembler le flux de travail complet

 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'

Vous pouvez également trouver un exemple de thème WordPress et de flux de travail GitHub Actions sur ce référentiel GitHub.

Conclusion

Voilà! GitHub Actions est un outil puissant qui facilite l'automatisation de la création et du déploiement de vos thèmes et plugins WordPress.

Nous avons à peine effleuré la surface de ce que vous pouvez réaliser avec GitHub Actions. Vos prochaines étapes pourraient être d'exécuter automatiquement tous les tests que vous pourriez avoir, d'ouvrir des problèmes ou de notifier sur Slack lorsqu'un déploiement est terminé, et la liste continue.

Jetez un œil au marché GitHub où, au moment de la rédaction, vous pouvez trouver plus de 15 000 actions à utiliser dans vos flux de travail GitHub Actions.

Alors qu'est-ce que tu attends?

• Jetez un œil au workflow de ce dépôt sur GitHub
• Créez un nouveau fichier YAML sous .github/workflows/ dans votre référentiel Git
• Bénéficiez de builds et de déploiements automatisés

Bons déploiements !