Erstellen eines CI/CD-Workflows – Automatisches Bereitstellen eines WordPress-Designs mit GitHub-Aktionen

Einführung

In der modernen Webentwicklung müssen Sie häufig mehrere Schritte ausführen, um Ihren Code zu erstellen und für die Produktion bereitzustellen. Für ein WordPress-Theme oder -Plug-in kann das bedeuten, Composer- und/oder Node.js-Abhängigkeiten zu installieren, CSS zu kompilieren, JavaScript zu transpilieren und Dateien auf Ihren Server hochzuladen.

In diesem Artikel untersuchen wir, wie Sie Ihren WordPress-Bereitstellungsprozess mithilfe von GitHub-Aktionen optimieren können. Wir erstellen einen GitHub Actions-Workflow, um automatisch ein WordPress-Design zu erstellen und auf Ihrer Pressidium-WordPress-Site bereitzustellen.

Wenn Sie nur für den Workflow geklickt haben, scrollen Sie zum Ende dieses Beitrags und tauchen Sie sofort ein. Wir empfehlen Ihnen jedoch, den gesamten Artikel zu lesen, in dem wir erklären, wie alles im Detail funktioniert!

Voraussetzungen

• Ein grundlegendes Verständnis von Git (Erstellen eines Repositorys, Commit und Pushen von Code, Erstellen von Branches usw.)
• Vertrautheit mit der Oberfläche von GitHub

Was ist „Bereitstellung“ in der Webentwicklung?

Die Bereitstellung in der Webentwicklung ist der Prozess, bei dem Änderungen in eine Remoteumgebung übertragen werden, um eine Website oder Anwendung zur Nutzung verfügbar zu machen.

Manchmal verwenden wir den Begriff „Bereitstellung“ für eine Reihe von Aktivitäten – darunter das Erstellen, Testen und Übertragen von Dateien –, während wir ihn manchmal synonym mit Dateiübertragung verwenden. In diesem Artikel unterscheiden wir immer zwischen Erstellen und Bereitstellen von .

Es gibt viele Möglichkeiten, die Dateien Ihrer Website an einen Hosting-Anbieter zu übertragen. In unserem Fall verwenden wir das Secure File Transfer Protocol (SFTP), das, wie der Name schon sagt, ein Netzwerkprotokoll zum Übertragen von Dateien über einen sicheren Kanal wie SSH ist.

Was sind GitHub-Aktionen?

GitHub Actions ist eine Plattform für kontinuierliche Integration und kontinuierliche Bereitstellung (CI/CD), mit der Sie Ihre Build- und Bereitstellungspipeline automatisieren können.

In den folgenden Abschnitten untersuchen wir, wie Sie einen GitHub Actions-Workflow zum Erstellen und Bereitstellen eines WordPress-Designs erstellen und dabei einen Hosting-Anbieter nutzen, der Staging-Umgebungen unterstützt.

Staging ist eine Vorproduktionsumgebung zum Testen, die nahezu eine exakte Nachbildung einer Produktionsumgebung ist. Es soll eine tatsächliche Produktionsumgebung so genau wie möglich widerspiegeln, sodass Änderungen dort getestet werden können, bevor sie auf eine Produktionsumgebung angewendet werden.

Wenn Sie Pressidium bereits verwenden, sind Staging-Umgebungen kostenlos in allen Plänen enthalten. Lesen Sie diesen KB-Artikel für weitere Informationen.

Was ist ein GitHub Actions-Workflow?

Ein Workflow ist ein automatisierter Prozess, der durch ein oder mehrere Ereignisse ausgelöst wird und einen oder mehrere Jobs ausführt . Jeder Job enthält einen oder mehrere Schritte . Schließlich kann jeder Schritt entweder ein Skript oder eine GitHub-Aktion ausführen. Ein Repository kann mehrere Workflows haben, die unterschiedliche Aufgaben ausführen.

Die Verwendung eines GitHub Actions-Workflows bietet viele Vorteile.

• Sie verbringen weniger Zeit mit manueller, arbeitsintensiver, sich wiederholender Arbeit; mehr Zeit für die Wertschöpfung
• Es ist einfacher, umgebungsübergreifend konsistent zu sein, indem ein bestimmter Bereitstellungsprozess erzwungen wird
• Es lässt sich in Ihr GitHub-Repository integrieren, sodass Sie Änderungen nachverfolgen, auf Bereitstellungsprotokolle zugreifen usw.
• Es ist wiederverwendbar, was bedeutet, dass Sie denselben Workflow in allen Ihren Repositories verwenden können

Einstieg

Beginnen wir mit Ihrem allerersten Workflow, indem Sie eine neue YAML-Datei im .github/workflows/ in Ihrem GitHub-Repository erstellen. Wir beginnen mit einem einfachen Workflow zur automatischen Bereitstellung in der Produktion, also nennen wir diese Datei deploy.yml .

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

Wir verwenden das Schlüsselwort on , um zu definieren, welche Ereignisse den Workflow auslösen können. In diesem Beispiel wird der Workflow ausgeführt, wenn ein Push an den main erfolgt.

Wir müssen wahrscheinlich überhaupt nicht bereitstellen, wenn sich bestimmte Dateien ändern, wie z. B. README.md . Wir können on.push.paths-ignore verwenden, um Dateipfadmuster auszuschließen.

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

Erstellen Sie Ihren ersten Job

Ein Workflow besteht aus einem oder mehreren Jobs. In diesem Beispiel verwenden Sie einen einzelnen deploy , um Ihre Dateien in die Produktionsumgebung Ihrer Website hochzuladen.

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

Jeder Job wird in einer Runner-Umgebung ausgeführt, die durch runs-on angegeben wird. Im obigen YAML-Block verwenden wir ubuntu-latest , eine virtuelle Ubuntu-Linux-Maschine (VM), die von GitHub mit der Runner-Anwendung und anderen vorinstallierten Tools gehostet wird.

Sie können entweder einen von GitHub gehosteten Runner verwenden oder Ihre eigenen Runner hosten und die zum Ausführen von Jobs verwendete Umgebung anpassen. Letzteres ist jedoch nicht Gegenstand dieses Artikels.

Überprüfen Sie Ihr Git-Repository

Bevor Sie etwas Sinnvolles mit Ihrem Code tun können, müssen Sie Ihr Repository auschecken , damit Ihr Workflow darauf zugreifen kann. Sie können dafür die Checkout -Aktion verwenden.

 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

Wir geben eine fetch-depth von 0 an, was dazu führt, dass der gesamte Git-Verlauf abgerufen wird. Wir benötigen dies, um nur Dateien hochzuladen, die sich in nachfolgenden Läufen geändert haben.

Erstellen eines SFTP-Benutzers

Um Ihre Dateien zu Ihrem Hosting-Anbieter hochzuladen, benötigen Sie Ihre SFTP-Verbindungsdetails (dh Host, Netzwerkport und Pfad) und einen SFTP-Benutzer.

Meistens können Sie diese Details finden und einen SFTP-Benutzer über das Dashboard Ihres Hosting-Providers erstellen. Einige Webhoster senden Ihnen diese Details auch per E-Mail.

Wenn Sie Pressidium bereits verwenden, gehen Sie folgendermaßen vor:

1. Melden Sie sich bei Ihrem Pressidium-Dashboard an
2. Wählen Sie in der Seitenleiste des Dashboards die Menüoption Websites aus
3. Klicken Sie auf den Namen Ihrer Website
4. Navigieren Sie zur Registerkarte SFTP , indem Sie auf den Link in der Navigationsleiste klicken
5. Notieren Sie sich Ihre SFTP-Verbindungsdetails
6. Erstellen Sie einen neuen SFTP-Benutzer

So erstellen Sie einen neuen SFTP-Benutzer:

1. Klicken Sie auf Neu
2. Wählen Sie die Umgebung ( Produktion oder Staging )
3. Geben Sie einen Benutzernamen und ein Passwort an (ein starkes Passwort, gemischte lateinische Klein- und Großbuchstaben, Zahlen und Sonderzeichen werden empfohlen)
4. Notieren Sie sich den eingegebenen Benutzernamen und das Passwort
5. Klicken Sie auf Erstellen , um den Benutzer zu erstellen

Im zweiten Schritt sollten Sie die Umgebung auswählen, in der Sie bereitstellen möchten. In diesem Beispiel erstellen wir einen Benutzer für jede Umgebung.

Hosten Sie Ihre Website mit Pressidium

60- TÄGIGE GELD-ZURÜCK-GARANTIE

SEHEN SIE UNSERE PLÄNE

Weitere Informationen zum Zugriff auf Ihre Pressidium WordPress-Site über SFTP finden Sie in diesem KB-Artikel.

Speichern sensibler Informationen

Sie können Ihre SFTP-Verbindungsdetails und SFTP-Benutzeranmeldeinformationen direkt in Ihren GitHub Actions-Workflow eingeben. Es ist jedoch keine gute Idee, vertrauliche Informationen in Ihrem Repository zu speichern.

GitHub bietet verschlüsselte Geheimnisse als Möglichkeit, vertrauliche Informationen in Ihrer Organisation, Ihrem Repository oder Ihrer Repository-Umgebung zu speichern.

So erstellen Sie ein verschlüsseltes Geheimnis für ein Repository:

1. Melden Sie sich bei Ihrem GitHub-Konto an
2. Navigieren Sie zur Hauptseite Ihres Repositorys
3. Klicken Sie unter Ihrem Repository-Namen auf Einstellungen
4. Wählen Sie Geheimnisse aus und klicken Sie unter dem Abschnitt Sicherheit der Seitenleiste auf Aktionen
5. Klicken Sie auf die Schaltfläche Neues Repository-Geheimnis
6. Geben Sie den geheimen Namen und seinen Wert ein
7. Klicken Sie auf Geheimnis hinzufügen

Sie sollten am Ende eine Liste mit Geheimnissen haben, die dieser ähnelt:

• SFTP_HOST Der Hostname des SFTP-Servers
• SFTP_PORT Der Port des SFTP-Servers
• SFTP_USER Der für die Authentifizierung zu verwendende Benutzername
• SFTP_PASS Das für die Authentifizierung zu verwendende Passwort

Hochladen von Dateien über SFTP

Um Ihre Dateien über SFTP hochzuladen, können Sie – Sie haben es erraten – eine andere GitHub-Aktion verwenden.

Es stehen mehrere SFTP-Clients und GitHub-Aktionen zur Auswahl. Wir haben uns für unsere eigene lftp-Mirror-Action entschieden, die lftp unter der Haube verwendet. Ein Dateiübertragungstool, das SFTP unterstützt und mehrere Dateien parallel übertragen kann.

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

Die Konfiguration der Eingänge der lftp-Mirror-Action ist ziemlich einfach:

• Auf Ihre SFTP-Verbindungsdetails und SFTP-Benutzeranmeldeinformationen kann über den secrets -Kontext zugegriffen werden (z. B. ${{ secrets.SFTP_HOST }} ).
• Das remoteDir ist der Pfad zum Verzeichnis Ihres Designs
• Die Option '--verbose' aktiviert die ausführliche Ausgabe, die alle Dateiübertragungen protokolliert (nützlich für die Fehlerbehebung).

Auf Pressidium werden Pfade wie folgt formatiert:

• YOUR_INSTALLATION_NAME-www/ als Stammpfad der Produktionsumgebung
• YOUR_INSTALLATION_NAME-dev-www/ als Root-Pfad der Staging -Umgebung

wobei YOUR_INSTALLATION_NAME der Name Ihrer Installation ist. Beachten Sie, dass der Kontoinhaber ein SFTP-Konto hat, das als „Master“-Konto angezeigt wird und Zugriff auf alle Websites hat, sodass sich ihre Pfade von den oben genannten unterscheiden. Es wird empfohlen, dieses Konto nicht zu verwenden und stattdessen für jede Website, auf die Sie zugreifen möchten, ein separates Konto zu erstellen.

Optional können Sie eine .lftp_ignore -Datei in Ihrem Repository erstellen, einschließlich aller Dateimuster, die Sie von der Bereitstellung ausschließen möchten.

Hier ein Beispiel, wie das aussehen könnte:

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

Alles zusammenfügen

 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'

Das ist es! Ihr Workflow kann Ihr WordPress-Design jetzt automatisch bereitstellen.

Erstellen und Bereitstellen Ihres WordPress-Themes

Bisher haben wir die Dinge einfach gehalten, indem wir uns darauf konzentriert haben, nur Ihre Dateien bereitzustellen, während wir alle Abhängigkeiten ignorieren, die Sie möglicherweise installieren müssen, Skripts erstellen, die Sie möglicherweise ausführen müssen, und so weiter und so fort.

Als Beispiel-Setup verwenden wir ein GitHub-Repository mit zwei Branches:

• der stabile, produktionsbereite main , der in einer Produktionsumgebung bereitgestellt wird
• der ungetestete preview -Zweig, der als Integrationszweig für Funktionen dient und in einer Staging -Umgebung bereitgestellt wird

Es ist an der Zeit, einen build -Job einzuführen und unseren Workflow in build-deploy umzubenennen, da er für das Erstellen und Bereitstellen unseres Codes verantwortlich sein wird.

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

Überprüfen Sie Ihr Git-Repository

Jeder Job wird in einer neuen Instanz eines Runner-Images ausgeführt, sodass Sie Ihr GitHub-Repository im build -Job erneut auschecken müssen.

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

Sie müssen nicht den gesamten Git-Verlauf im Build-Job abrufen, sodass Sie bei den Standardwerten für die Eingaben der Aktion bleiben können.

Abhängigkeiten installieren

Einige Themen verwenden Pakete und Bibliotheken von Drittanbietern. Wenn Ihr Thema PHP- und/oder JavaScript-Pakete erfordert, möchten Sie möglicherweise einen Paketmanager wie Composer, npm oder Garn verwenden.

Für dieses Beispiel gehen wir davon aus, dass Sie sowohl Composer- als auch Node.js-Abhängigkeiten installieren müssen. Glücklicherweise gibt es dafür fertige Aktionen.

 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

Die Composer -Aktion führt standardmäßig die composer install aus, sodass Sie keine ihrer Eingabeparameter konfigurieren müssen.

Für die Aktion setup-node legen wir benutzerdefinierte Werte für die node-version und die cache -Eingaben fest, um Folgendes anzugeben:

• Holen Sie sich die Version mit langfristigem Support (oder LTS) von Node.js
• Zwischenspeichern Sie alle Abhängigkeiten, die über den Garnpaket-Manager abgerufen wurden

Im nächsten Schritt wird dann die yarn install ausgeführt, um die Node.js-Abhängigkeiten zu installieren. Denken Sie daran, dass ein Schritt entweder ein Skript oder eine GitHub-Aktion ausführen kann.

Beachten Sie, dass Caching Ihren Arbeitsablauf erheblich beschleunigen kann. Das Herunterladen von Abhängigkeiten bei jeder Ausführung Ihres Workflows führt zu einer längeren Laufzeit. Sie können Abhängigkeiten für einen Job mithilfe der Cache -Aktion zwischenspeichern (was auch die setup-node Aktion unter der Haube tut), wodurch die Zeit verkürzt wird, die zum Neuerstellen von Dateien benötigt wird.

Ausführen Ihres Build-Prozesses

Auch hier gehen wir davon aus, dass Sie einen „Build“-Prozess ausführen müssen – Sie müssen möglicherweise einen Präprozessor ausführen, um Ihre Stylesheets zu kompilieren, Ihre ES6+-Skripte zu transpilieren usw. Das bedeutet normalerweise, dass Sie ein build -Skript in Ihrem definiert haben package.json -Datei.

Sie benötigen also einen weiteren Schritt, um diesen Build-Prozess auszuführen.

 - name: Build theme run: yarn run build

Wenn Sie ein anderes Skript für die main und preview ausführen müssen (z. B. build für den main und staging für die preview ), können Sie dies folgendermaßen tun:

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

Da schließlich jeder Job in einer neuen Instanz eines Runner-Images ausgeführt wird, sind Jobs in Ihrem Workflow vollständig isoliert. Das bedeutet, dass Sie die gerade erstellten Dateien vorübergehend speichern müssen, damit der deploy darauf zugreifen kann. Geben Sie Artefakte ein.

Artefakte

Artefakte ermöglichen es Ihnen, Daten nach Abschluss eines Jobs beizubehalten, sodass Sie Daten zwischen Jobs in einem Workflow gemeinsam nutzen können.

Lassen Sie uns einen zusätzlichen Schritt in Ihren build -Job einführen, um Daten, die während der Build-Schritte erstellt wurden, mit einer Aufbewahrungsfrist von 1 Tag unter Verwendung der Upload-Artifact- Aktion beizubehalten. Wir gehen davon aus, dass Composer seine Abhängigkeiten im Verzeichnis „ vendor/ “ installiert und unser build -Skript Dateien in das Verzeichnis dist/ exportiert.

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

Abhängig von der Größe Ihres Repositorys und wie oft Sie Pushen, sollten Sie sich die Nutzungsbeschränkungen, Abrechnung und Verwaltung von GitHub ansehen.

Zum Zeitpunkt des Verfassens dieses Artikels speichert GitHub standardmäßig Build-Protokolle und Artefakte für 90 Tage und stellt 500 MB Speicherplatz im Plan „GitHub Free“ bereit.

Jobs sequentiell ausführen

Ein Workflow besteht aus einem oder mehreren Jobs, die standardmäßig parallel laufen. In unserem Fall müssen wir unser Thema erstellen, bevor wir es bereitstellen können. Um Ihre build und deploy -Jobs sequenziell auszuführen, müssen Sie eine Abhängigkeit mit dem Schlüsselwort jobs.<job_id>.needs .

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

Im folgenden Beispiel geben wir an, dass der build erfolgreich abgeschlossen werden muss, bevor der deploy ausgeführt werden kann.

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

Herunterladen des Artefakts

Bevor Sie während der Erstellungsschritte erstellte Daten hochladen können, müssen Sie sie herunterladen. Sehen wir uns den deploy noch einmal an und führen einen zusätzlichen Schritt ein.

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

Sie können die Aktion Download -Arti fact ähnlich wie Upload-Artifact verwenden. Stellen Sie sicher, dass Sie für beide Aktionen denselben Namen angeben – in diesem Fall my-theme-build .

Alles zusammenfügen

 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'

Jetzt haben Sie einen GitHub Actions-Workflow, der Ihren Code automatisch erstellen und für die Produktion bereitstellen kann, wenn Sie ihn zum main pushen! Am Anfang dieses Artikels haben wir jedoch einen Workflow beschrieben, der je nach Branche, in die Sie pushen, sowohl in Produktions- als auch in Staging-Umgebungen bereitgestellt werden kann. Wenn Sie immer noch Lust darauf haben, lesen Sie einfach weiter!

Bereitstellen Ihres Designs in mehreren Umgebungen

Die Bereitstellung in mehreren Umgebungen erfordert möglicherweise eine geringfügige Änderung Ihres Arbeitsablaufs. Beispielsweise wird häufig empfohlen und als Best Practice angesehen, separate SFTP-Benutzer für jede Umgebung zu haben. In Pressidium unterscheiden sich SFTP-Benutzer für die Produktions- und Bereitstellungsumgebungen einer Website.

Lassen Sie uns also verschiedene Geheimnisse für den Benutzernamen/das Passwort jedes Benutzers erstellen. Das bedeutet, dass unsere aktualisierte Liste verschlüsselter Geheimnisse wie folgt aussehen sollte:

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

Möglicherweise müssen Sie auch den Host und den Netzwerkport aktualisieren. In diesem Fall müssen diese jedoch nicht geändert werden, da sie für beide Umgebungen identisch sind.

Umgebungsvariablen setzen

Eine Umgebungsvariable ist eine Variable, die aus einem Name/Wert-Paar besteht und Teil der Umgebung ist, in der ein Prozess ausgeführt wird.

In einem GitHub Actions-Workflow können Sie das Schlüsselwort env verwenden, um eine benutzerdefinierte Umgebungsvariable festzulegen, die für Folgendes gilt:

• Der gesamte Workflow, indem env auf der obersten Ebene des Workflows verwendet wird
• Ein Job innerhalb eines Workflows, indem env auf der Ebene dieses Jobs verwendet wird
• Ein bestimmter Schritt innerhalb eines Jobs, indem env auf der Ebene dieses Schritts verwendet wird

Sie können auch Umgebungsvariablen an $GITHUB_ENV anhängen, wodurch diese Variable für alle nachfolgenden Schritte in einem Workflow-Job verfügbar wird.

Wie Sie sehen, gibt es mehrere Möglichkeiten, Ihre Workflows zu erstellen. Verwenden Sie also das, was für Sie am sinnvollsten ist.

In unserem Fall setzen wir Umgebungsvariablen innerhalb eines Schritts eines Jobs, um Werte vorübergehend zu speichern und von einem anderen Schritt, der später in unserem Workflow ausgeführt wird, darauf zuzugreifen. Wir hängen Umgebungsvariablen an $GITHUB_ENV innerhalb von Schritten an, die für push -Ereignisse an bestimmte Zweige ausgeführt werden, um zu zeigen, wie Sie Ihre benutzerdefinierten Variablen bedingt festlegen können.

 - 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

Wir verwenden das Schlüsselwort if , um jeden Schritt auf einen bestimmten Zweig zu beschränken. Auf diese Weise wird Set environment variables (main) nur ausgeführt, wenn Änderungen an den main Zweig gepusht wurden.

Der $DEPLOY_PATH kann sich auch für jede Umgebung unterscheiden.

Zum Beispiel auf Pressidium:

• Pfade für Produktionsumgebungen folgen dem Format /<WEBSITE_NAME>-www/
• Pfade für Staging-Umgebungen folgen dem Format /<WEBSITE_NAME>-dev-www/

Ausgänge setzen

Wir möchten die Umgebungsvariablen, die wir gerade festgelegt haben, als Eingaben für die GitHub-Aktion verwenden, die Dateien über SFTP übertragen wird.

Leider scheint es im Moment nicht möglich zu sein, Umgebungsvariablen als Eingaben einer GitHub-Aktion zu referenzieren. Sie können dies umgehen, indem Sie einen zusätzlichen Schritt erstellen, der die Werte ausgibt, die Sie später als Eingaben verwenden müssen.

 - 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

Sie haben jetzt die Ausgaben user , pass und deploy_path für den Schritt sftp_details , die Sie verwenden können, um auf diese Werte als Eingaben für Ihren nächsten Schritt zu verweisen.

Hochladen von Dateien in verschiedene Umgebungen

Das Hochladen von Dateien über SFTP ist im Wesentlichen dasselbe wie zuvor, aber anstatt auf den secrets -Kontext zu verweisen und remoteDir fest zu codieren, verwenden Sie die Ausgaben des vorherigen Schritts.

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

Verwenden Sie ${{ steps.<step_id>.outputs.<output_name> }} , um auf die Ausgabe eines Schritts zuzugreifen. Beispiel: ${{ steps.sftp_details.outputs.user }} für den Zugriff auf die user des Schritts sftp_details .

Puh, endlich! Ihr Workflow kann jetzt Ihr WordPress-Theme sowohl in Ihrer Produktions- als auch in Ihrer Staging-Umgebung erstellen und bereitstellen.

Den kompletten Workflow zusammenstellen

 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'

In diesem GitHub-Repository finden Sie auch ein Beispiel für ein WordPress-Design und einen GitHub Actions-Workflow.

Fazit

Hier hast du es! GitHub-Aktionen sind ein leistungsstarkes Tool, mit dem Sie das Erstellen und Bereitstellen Ihrer WordPress-Designs und -Plugins einfach automatisieren können.

Wir haben kaum an der Oberfläche dessen gekratzt, was Sie mit GitHub Actions erreichen können. Ihre nächsten Schritte könnten darin bestehen, eventuell vorhandene Tests automatisch auszuführen, Probleme zu öffnen oder auf Slack zu benachrichtigen, wenn eine Bereitstellung abgeschlossen ist, und die Liste geht weiter.

Werfen Sie einen Blick auf den GitHub Marketplace, wo Sie – zum Zeitpunkt der Erstellung dieses Artikels – über 15.000 Aktionen finden, die Sie in Ihren GitHub Actions-Workflows verwenden können.

Also, worauf wartest Du?

• Sehen Sie sich den Workflow dieses Repositorys auf GitHub an
• Erstellen Sie eine neue YAML-Datei unter .github/workflows/ in Ihrem Git-Repository
• Profitieren Sie von automatisierten Builds und Bereitstellungen

Fröhliche Einsätze!