Construirea unui flux de lucru CI/CD - Implementarea automată a unei teme WordPress cu acțiuni GitHub

Introducere

În dezvoltarea web modernă, există adesea mai mulți pași pe care trebuie să îi faceți pentru a construi și a implementa codul în producție. Pentru o temă sau un plugin WordPress, asta ar putea însemna instalarea dependențelor Composer și/sau Node.js, compilarea CSS, transpilarea JavaScript și încărcarea fișierelor pe serverul dvs.

În acest articol, vom explora modul în care vă puteți eficientiza procesul de implementare WordPress folosind GitHub Actions. Vom crea un flux de lucru GitHub Actions pentru a construi și a implementa automat o temă WordPress pe site-ul dvs. WordPress Pressidium.

Dacă ați făcut clic doar pentru fluxul de lucru, derulați până la partea de jos a acestei postări și accesați imediat. Cu toate acestea, vă încurajăm să citiți întregul articol, unde vă explicăm în detaliu cum funcționează totul!

Cerințe preliminare

• O înțelegere de bază a Git (crearea unui depozit, comiterea și împingerea codului, crearea de ramuri etc.)
• Familiaritate cu interfața GitHub

Ce înseamnă „implementarea” în dezvoltarea web?

Implementarea în dezvoltarea web este procesul de împingere a modificărilor într-un mediu la distanță, făcând un site web sau o aplicație disponibilă pentru utilizare.

Uneori folosim termenul „implementare” pentru a ne referi la un set de activități – care includ construirea, testarea și transferul de fișiere – în timp ce alteori îl folosim ca sinonim cu transferul de fișiere. În acest articol, facem întotdeauna distincția între construirea și implementarea .

Există multe modalități de a trimite fișierele site-ului dvs. către un furnizor de găzduire. În cazul nostru, vom folosi Secure File Transfer Protocol (SFTP) care, după cum sugerează și numele, este un protocol de rețea pentru transferul de fișiere pe un canal securizat, cum ar fi SSH.

Ce este GitHub Actions?

GitHub Actions este o platformă de integrare continuă și livrare continuă (CI/CD) care vă permite să vă automatizați canalul de construire și implementare.

În paragrafele următoare, vom explora cum să creăm un flux de lucru GitHub Actions pentru a construi și a implementa o temă WordPress utilizând un furnizor de găzduire care acceptă medii de pregătire.

Stagingul este un mediu de pre-producție pentru testare, care este aproape o replică exactă a unui mediu de producție. Acesta caută să reflecte cât mai aproape posibil un mediu de producție real, astfel încât modificările pot fi testate acolo înainte de a fi aplicate într-un mediu de producție.

Dacă utilizați deja Pressidium, mediile de organizare sunt incluse gratuit în toate planurile. Citiți acest articol KB pentru mai multe informații.

Ce este un flux de lucru GitHub Actions?

Un flux de lucru este un proces automat care este declanșat de unul sau mai multe evenimente și rulează una sau mai multe joburi . Fiecare job conține unul sau mai mulți pași . În cele din urmă, fiecare pas poate rula fie un script, fie o acțiune GitHub. Un depozit poate avea mai multe fluxuri de lucru, efectuând diferite sarcini.

Există multe beneficii în utilizarea unui flux de lucru GitHub Actions.

• Petreci mai puțin timp lucrând manual, cu forță de muncă intensivă și repetitivă; mai mult timp adăugând valoare
• Este mai ușor să fii consecvent în medii prin aplicarea unui anumit proces de implementare
• Se integrează cu depozitul dvs. GitHub, permițându-vă să urmăriți modificările, să accesați jurnalele de implementare etc.
• Este reutilizabil, ceea ce înseamnă că puteți utiliza același flux de lucru în toate depozitele dvs

Noțiuni de bază

Să începem cu primul tău flux de lucru prin crearea unui nou fișier YAML în directorul .github/workflows/ din depozitul tău GitHub. Vom începe cu un flux de lucru simplu pentru implementarea automată în producție, așa că haideți să numim acest fișier deploy.yml .

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

Folosim cuvântul cheie on pentru a defini ce evenimente pot declanșa fluxul de lucru. În acest exemplu, fluxul de lucru va rula atunci când se face o împingere către ramura main .

Probabil că nu trebuie să implementăm deloc atunci când anumite fișiere se schimbă, cum ar fi README.md . Putem folosi on.push.paths-ignore pentru a exclude modelele de căi de fișiere.

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

Crearea primului tău loc de muncă

Un flux de lucru este format din una sau mai multe locuri de muncă. În acest exemplu, veți folosi o singură lucrare de deploy pentru a vă încărca fișierele în mediul de producție al site-ului dvs. web.

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

Fiecare job rulează într-un mediu de rulare, specificat de runs-on . În blocul YAML de mai sus, folosim ubuntu-latest care este o mașină virtuală Ubuntu Linux (VM), găzduită de GitHub cu aplicația runner și alte instrumente preinstalate.

Puteți fie să utilizați un alergător găzduit de GitHub, fie să vă găzduiți propriii alergători și să personalizați mediul folosit pentru a rula joburi. Cu toate acestea, acesta din urmă nu intră în domeniul de aplicare al acestui articol.

Verificați depozitul dvs. Git

Înainte de a putea face ceva semnificativ cu codul dvs., trebuie să verificați depozitul, astfel încât fluxul de lucru să îl poată accesa. Puteți utiliza acțiunea de checkout pentru asta.

 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

Specificăm o fetch-depth de 0 , care va avea ca rezultat preluarea întregului istoric Git. Avem nevoie de aceasta pentru a încărca numai fișierele care s-au modificat în rulările ulterioare.

Crearea unui utilizator SFTP

Pentru a vă încărca fișierele la furnizorul dvs. de găzduire, veți avea nevoie de detaliile conexiunii SFTP (adică gazdă, portul de rețea și calea) și de un utilizator SFTP.

De cele mai multe ori, puteți găsi aceste detalii și puteți crea un utilizator SFTP prin tabloul de bord al furnizorului dvs. de găzduire. Unele gazde web vă vor trimite prin e-mail aceste detalii.

Dacă utilizați deja Pressidium, urmați acești pași:

1. Conectați-vă la tabloul de bord Pressidium
2. Selectați opțiunea de meniu Site -uri din bara laterală a tabloului de bord
3. Faceți clic pe numele site-ului dvs
4. Navigați la fila SFTP făcând clic pe linkul din bara de navigare
5. Notă detaliile conexiunii SFTP
6. Creați un nou utilizator SFTP

Pentru a crea un nou utilizator SFTP:

1. Faceți clic pe Nou
2. Selectați mediul ( producție sau montare )
3. Furnizați un nume de utilizator și o parolă (se recomandă o parolă puternică, caractere latine litere mici și majuscule, numere și caractere speciale sunt recomandate)
4. Notați numele de utilizator și parola pe care le-ați introdus
5. Faceți clic pe Creare pentru a crea utilizatorul

La al doilea pas, ar trebui să alegeți mediul în care doriți să vă implementați. Pentru acest exemplu, vom crea un utilizator pentru fiecare mediu.

Găzduiește-ți site-ul web cu Pressidium

60 DE ZILE GARANȚIE BANI RAPIS

VEZI PLANUL NOSTRU

Pentru mai multe informații despre accesarea site-ului dvs. WordPress Pressidium prin SFTP, consultați acest articol KB.

Stocarea informațiilor sensibile

Puteți introduce detaliile conexiunii SFTP și acreditările de utilizator SFTP direct în fluxul de lucru GitHub Actions. Cu toate acestea, stocarea informațiilor sensibile în depozitul dvs. este o idee proastă.

GitHub oferă secrete criptate ca o modalitate de a stoca informații sensibile în organizația, depozitul sau mediul de depozitare.

Pentru a crea un secret criptat pentru un depozit:

1. Conectați-vă la contul dvs. GitHub
2. Navigați la pagina principală a depozitului dvs
3. Sub numele depozitului, faceți clic pe Setări
4. Selectați Secrete și faceți clic pe Acțiuni , sub secțiunea Securitate a barei laterale
5. Faceți clic pe butonul Nou secret al depozitului
6. Introduceți numele secret și valoarea acestuia
7. Faceți clic pe Adăugați secret

Ar trebui să ajungeți cu o listă de secrete asemănătoare cu aceasta:

• SFTP_HOST Numele de gazdă al serverului SFTP
• SFTP_PORT Portul serverului SFTP
• SFTP_USER Numele de utilizator de utilizat pentru autentificare
• SFTP_PASS Parola de utilizat pentru autentificare

Încărcarea fișierelor prin SFTP

Pentru a vă încărca fișierele prin SFTP, puteți utiliza – ați ghicit – o altă acțiune GitHub.

Există mai mulți clienți SFTP și acțiuni GitHub din care să alegeți. Am mers cu propriul nostru lftp-mirror-action , care folosește lftp sub capotă. Un instrument de transfer de fișiere care acceptă SFTP și poate transfera mai multe fișiere în paralel.

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

Configurarea intrărilor lftp-mirror-action este destul de simplă:

• Detaliile dvs. de conexiune SFTP și acreditările de utilizator SFTP pot fi accesate prin contextul secrets (de ex. ${{ secrets.SFTP_HOST }} )
• remoteDir este calea către directorul temei tale
• Opțiunea '--verbose' va activa o ieșire detaliată, care va înregistra toate transferurile de fișiere (utilă pentru depanare)

Pe Pressidium, căile sunt formatate astfel:

• YOUR_INSTALLATION_NAME-www/ ca cale rădăcină a mediului de producție
• YOUR_INSTALLATION_NAME-dev-www/ ca cale rădăcină a mediului de pregătire

unde YOUR_INSTALLATION_NAME este numele instalării dvs. Rețineți că proprietarul contului are un cont SFTP, afișat ca cont „master”, care are acces la toate site-urile web, așa că căile lor vor diferi de cele de mai sus. Se recomandă să evitați utilizarea acestui cont și, în schimb, să creați un cont separat pentru fiecare site web pe care doriți să îl accesați.

Opțional, puteți crea un fișier .lftp_ignore în depozitul dvs., inclusiv orice tipare de fișiere pe care doriți să le excludeți de la implementare.

Iată un exemplu despre cum ar putea arăta:

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

Punând totul împreună

 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'

Asta e! Fluxul de lucru vă poate implementa acum automat tema WordPress.

Crearea și implementarea temei dvs. WordPress

Până acum, am păstrat lucrurile simple concentrându-ne doar pe implementarea fișierelor dvs. ignorând orice dependențe pe care ați putea avea nevoie să le instalați, să construim scripturi pe care ați putea avea nevoie să le rulați și așa mai departe și așa mai departe.

Ca exemplu de configurare, vom folosi un depozit GitHub cu două ramuri:

• ramura main stabilă, pregătită pentru producție, care va fi implementată într-un mediu de producție
• ramura de preview netestată, care servește ca ramură de integrare pentru funcții și va fi implementată într-un mediu de pregătire

Este timpul să introduceți o sarcină de compilare și să redenumim fluxul de lucru în build build-deploy , deoarece va fi responsabil pentru construirea și implementarea codului nostru.

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

Verificați depozitul dvs. Git

Fiecare job rulează într-o instanță nouă a unei imagini de rulare, așa că trebuie să verificați din nou depozitul GitHub în jobul de build .

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

Nu trebuie să preluați întregul istoric Git în sarcina de construire, așa că puteți rămâne cu valorile implicite pentru intrările acțiunii.

Instalarea dependențelor

Unele teme utilizează pachete și biblioteci terțe. Dacă tema dvs. necesită pachete PHP și/sau JavaScript, poate doriți să utilizați un manager de pachete, cum ar fi Composer, npm sau yarn.

De dragul acestui exemplu, vom presupune că trebuie să instalați atât dependențele Composer, cât și Node.js. Din fericire pentru noi, există acțiuni gata de utilizat pentru asta.

 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

Acțiunea de compoziție va rula composer install în mod implicit, deci nu trebuie să configurați niciunul dintre parametrii de intrare.

Pentru acțiunea setup-node , setăm valori personalizate pentru node-version și intrările cache pentru a specifica că dorim să:

• obțineți versiunea de suport pe termen lung (sau LTS) a Node.js
• memorați în cache orice dependențe preluate prin managerul de pachete yarn

Apoi, următorul pas va rula yarn install pentru a instala dependențele Node.js. Rețineți, un pas poate rula fie un script, fie o acțiune GitHub.

Rețineți că stocarea în cache vă poate accelera semnificativ fluxul de lucru. Descărcarea dependențelor de fiecare dată când rulează fluxul de lucru va avea ca rezultat o durată mai lungă de rulare. Puteți stoca în cache dependențele pentru o lucrare folosind acțiunea de cache (care este ceea ce face și acțiunea setup-node sub capotă), grărind timpul necesar pentru a recrea fișierele.

Rularea procesului de construire

Încă o dată, vom presupune că trebuie să executați un proces de „build”—s-ar putea să fie nevoie să rulați un preprocesor pentru a vă compila foile de stil, a build script-urile ES6+ etc. Aceasta înseamnă de obicei că ați definit un script de compilare în dvs. fișierul package.json .

Deci, veți avea nevoie de încă un pas pentru a rula acel proces de construire.

 - name: Build theme run: yarn run build

Dacă trebuie să rulați un script diferit pentru ramurile main și de preview (de exemplu, build pentru ramura main și staging pentru preview ), puteți face acest lucru astfel:

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

În cele din urmă, deoarece fiecare job rulează într-o instanță nouă a unei imagini de rulare, joburile din fluxul dvs. de lucru sunt complet izolate. Aceasta înseamnă că aveți nevoie de o modalitate de a stoca temporar fișierele pe care tocmai le-ați construit, astfel încât să poată fi accesate de jobul de deploy . Introduceți artefacte .

Artefacte

Artefactele vă permit să păstrați datele după ce o lucrare este finalizată, astfel încât să puteți partaja date între lucrări într-un flux de lucru.

Să introducem un pas suplimentar în sarcina dvs. de compilare pentru build păstra datele produse în timpul pașilor de compilare cu o perioadă de păstrare de 1 zi, utilizând acțiunea Încărcare-Artefact . Vom presupune că Composer build instalează dependențele în directorul vendor/ , iar scriptul nostru de compilare exportă fișiere în directorul dist/ .

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

În funcție de dimensiunea depozitului și de cât de des împingeți, este posibil să doriți să aruncați o privire la limitele de utilizare, facturarea și administrarea GitHub.

La momentul scrierii, în mod implicit, magazinele GitHub construiesc jurnalele și artefactele timp de 90 de zile și oferă 500 MB de spațiu de stocare în planul „GitHub Free”.

Rularea lucrărilor secvenţial

Un flux de lucru este format din una sau mai multe joburi, care rulează în paralel în mod implicit. În cazul nostru, trebuie să ne construim tema înainte de a o putea implementa. Pentru build rula secvențial joburile de compilare și deploy , trebuie să definiți o dependență folosind cuvântul cheie jobs.<job_id>.needs .

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

În exemplul de mai jos, afirmăm că sarcina de build trebuie să se termine cu succes înainte ca jobul de deploy poată rula.

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

Descărcarea artefactului

Înainte de a putea încărca orice date construite în timpul pașilor de construire, trebuie să le descărcați. Să revizuim jobul de deploy și să introducem un pas suplimentar.

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

Puteți utiliza acțiunea Descărcare - Artifact în mod similar cu Încărcare-Artifact . Asigurați-vă că specificați același nume— my-theme-build , în acest caz—pentru ambele acțiuni.

Punând totul împreună

 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'

Acum aveți un flux de lucru GitHub Actions care vă poate construi și implementa automat codul în producție atunci când împingeți la ramura main ! Cu toate acestea, la începutul acestui articol, am descris un flux de lucru care ar putea fi implementat atât în ​​mediile de producție, cât și în mediile de realizare, în funcție de ramura către care împingeți. Dacă tot ești pregătit, continuă să citești!

Implementarea temei în mai multe medii

Implementarea în mai multe medii poate necesita modificarea puțin fluxul de lucru. De exemplu, a avea utilizatori SFTP separati pentru fiecare mediu este adesea recomandată și considerată cea mai bună practică. În Pressidium, utilizatorii SFTP sunt diferiți pentru mediile de producție și de organizare a unui site web.

Deci, haideți să creăm diferite secrete pentru numele de utilizator/parola fiecărui utilizator. Asta înseamnă că lista noastră actualizată de secrete criptate ar trebui să arate astfel:

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

De asemenea, este posibil să trebuiască să actualizați gazda și portul de rețea. Deși, în acest caz, nu este nevoie să le schimbați, deoarece sunt identice pentru ambele medii.

Setarea variabilelor de mediu

O variabilă de mediu este o variabilă, formată dintr-o pereche nume/valoare și face parte din mediul în care rulează un proces.

Într-un flux de lucru GitHub Actions, puteți utiliza cuvântul cheie env pentru a seta o variabilă de mediu personalizată care este vizată:

• Întregul flux de lucru, prin utilizarea env la nivelul superior al fluxului de lucru
• Un job în cadrul unui flux de lucru, prin utilizarea env la nivelul jobului respectiv
• Un pas specific dintr-un job, prin utilizarea env la nivelul acelui pas

De asemenea, puteți adăuga variabile de mediu la $GITHUB_ENV , ceea ce face ca acea variabilă să fie disponibilă pentru orice pași ulterioare dintr-o lucrare de flux de lucru.

După cum puteți vedea, există mai multe moduri de a vă construi fluxurile de lucru. Așadar, nu ezitați să utilizați ceea ce are cel mai mult sens pentru dvs.

În cazul nostru, setăm variabile de mediu într-un pas al unui job pentru a stoca temporar valori și pentru a le accesa dintr-un alt pas care rulează mai târziu în fluxul nostru de lucru. Vom adăuga variabile de mediu la $GITHUB_ENV în cadrul pașilor care rulează pentru evenimente push către anumite ramuri, pentru a arăta cum vă puteți seta în mod condiționat variabilele personalizate.

 - 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

Folosim cuvântul cheie if pentru a limita fiecare pas la o anumită ramură. În acest fel, Setare variabile de mediu (principal) va rula numai dacă modificările au fost împinse în ramura main .

$DEPLOY_PATH poate diferi și pentru fiecare mediu.

De exemplu, pe Pressidium:

• Căile pentru mediile de producție urmează formatul /<WEBSITE_NAME>-www/
• Căile pentru mediile de pregătire urmează formatul /<WEBSITE_NAME>-dev-www/

Setarea ieșirilor

Am dori să folosim variabilele de mediu pe care tocmai le-am setat ca intrări în acțiunea GitHub, care va transfera fișiere prin SFTP.

Din păcate, în acest moment, nu pare să fie posibil să se facă referire la variabilele de mediu ca intrări ale unei acțiuni GitHub. Puteți rezolva asta prin crearea unui pas suplimentar care va scoate valorile pe care va trebui să le utilizați ca intrări mai târziu.

 - 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

Acum aveți ieșiri user , pass și deploy_path pentru pasul sftp_details , pe care le puteți utiliza pentru a face referire la aceste valori ca intrări ale pasului următor.

Încărcarea fișierelor în diferite medii

Încărcarea fișierelor prin SFTP este aproape la fel ca înainte, dar în loc să faceți referire la contextul secrets și să codificați hard-codarea remoteDir , veți folosi rezultatele pasului 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'

Utilizați ${{ steps.<step_id>.outputs.<output_name> }} pentru a accesa rezultatul unui pas. De exemplu, ${{ steps.sftp_details.outputs.user }} pentru a accesa rezultatul user din pasul sftp_details .

Pf, în sfârșit! Fluxul dvs. de lucru poate acum să construiască și să implementeze tema dvs. WordPress atât în ​​mediul dvs. de producție, cât și în cel de realizare.

Punerea laolaltă a fluxului de lucru 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'

Puteți găsi, de asemenea, un exemplu de temă WordPress și flux de lucru GitHub Actions în acest depozit GitHub.

Concluzie

Iată-l! GitHub Actions este un instrument puternic care facilitează automatizarea construirii și implementării temelor și pluginurilor dvs. WordPress.

Abia am zgâriat suprafața a ceea ce poți realiza cu GitHub Actions. Următorii pași ar putea fi rularea automată a oricăror teste pe care le aveți, deschiderea problemelor sau notificarea pe Slack atunci când se termină o implementare, iar lista continuă.

Aruncă o privire la Piața GitHub unde, la momentul scrierii, puteți găsi peste 15.000 de acțiuni de utilizat în fluxurile de lucru GitHub Actions.

Deci ce mai aștepți?

• Aruncă o privire la fluxul de lucru al acestui depozit pe GitHub
• Creați un nou fișier YAML sub .github/workflows/ în depozitul dvs. Git
• Bucurați-vă de versiuni și implementări automate

Desfăşurări fericite!