GitHub-handlinger som CI/CD for et websted på en statisk generator og GitHub-sider

GitHub-handlinger som CI/CD for et websted på en statisk generator og GitHub-sider

Efter at have gennemsøgt Habr lidt, var jeg overrasket over, at meget få artikler er blevet publiceret om emnet GitHubs (beta) funktion - Handlinger.

Det ser ud til, at en sådan underdrivelse kan forklares med, at funktionaliteten stadig er i test, omend "beta". Men det er en nyttig funktion i betaen, der gør det muligt at bruge dette værktøj i private depoter. Det handler om at arbejde med denne teknologi, som jeg vil tale om i denne artikel.

Oldtid

Hvis vi starter i rækkefølge, så er det nok værd at nævne, at i processen med at søge efter en hurtig, bekvem, nem og gratis mulighed for at gemme en personlig "Om mig" hjemmeside, var jeg nødt til at tilbringe flere nætter og finde mange artikler.

Nogle mennesker vælger hosting, andre en cloud-server, og dem, der ikke ønsker at forstå arbejdet, interaktionen og betalingen for alt dette som at uploade statiske websteder til et repository, da dette nu kan gøres på både GitHub og GitLab.

Dette er naturligvis alles personlige valg.

Mit endelige valg var GitHub Pages.

Om sider

Hvem ved ikke gh-pages - dette er en mulighed for opbevaring af dokumentation i form af en hjemmeside og den stilles gratis til rådighed, og udover dokumentation foreslås det også at opbevare personlige hjemmesider. Denne funktionalitet leveres af GitHub til alle brugere og er tilgængelig i lagerindstillingerne.

Projektdepotet bruger en filial gh-pages, for et brugersted - et separat lager med navnet username.github.io med webstedskilder i master afdeling.

Du kan se flere detaljer i dokumentation, men lad mig bare bemærke, at GitHub er overraskende generøs til at tillade enhver at linke deres eget domæne til et sådant websted ved blot at tilføje en fil CNAME med domænenavnet og opsætning af DNS for din domæneudbyder på GitHub-serverne.

Jeg er sikker på, at der er mange artikler her om, hvordan man udvikler sådan et websted, så det er ikke det, jeg vil tale om yderligere.

Forekomst af et problem

Problemet var, at når man bruger en statisk generator, er der behov for at skrive yderligere scripts og bruge biblioteker til at forenkle processen med at generere sider og indlæse dem i depotet. Simpelthen, hvis du gemmer kilderne i et separat privat depot, så hver gang der er nogen ændring på webstedet, var det nødvendigt at implementere det lokale miljø til den efterfølgende generation af statiske sider og offentliggørelse i hovedwebstedets lager.

Der er en overflod statiske generatorer og de har alle det samme problem. Disse handlinger tager for meget tid og kræfter og bremser i sidste ende arbejdet på webstedet, især efter adskillige migreringer fra OS til OS eller hændelser med datatab på harddiske (det var tilfældet i mit tilfælde).

For nylig blev der, enten i en pop-up notifikation på hjemmesiden eller i et nyhedsbrev fra GitHub, bemærket en nybygget CI/CD, som gjorde det muligt at udføre disse handlinger med minimal indsats.

Om statiske sidegeneratorer

Jeg vil ikke fokusere særlig opmærksomhed på dette underpunkt, men jeg vil dele et par afhandlinger, som jeg kom frem til under udvælgelsen og brugen af ​​følgende:

1) vælg en generator, der passer til dit programmeringssprog, eller en, der er så tydelig som muligt. Jeg kom til denne idé på et tidspunkt, hvor jeg selv skulle tilføje noget funktionalitet for at siden kunne fungere, tilføje krykker for dens større stabilitet og automatisering. Derudover er dette en god grund til selv at skrive yderligere funktionalitet i form af plugins;

2) hvilken generator du skal vælge er et personligt valg, men det er værd at overveje, at for den første fordybelse i arbejdet med GitHub Pages-funktionaliteten, skal du først installere Jekyll. Heldigvis giver det dig mulighed for at generere en hjemmeside fra kilder direkte i depotet (Jeg vil gentage dette med mit valg).

Mit valg af generator er baseret på det første punkt. Pelikan som er skrevet i Python erstattede let Jekyll, som er fremmed for mig (brugte den i næsten et år). Som et resultat giver selv oprettelse og redigering af artikler og arbejde på en hjemmeside yderligere erfaring på et sprog, der er interessant for mig.

__

Formulering af problemet

Hovedopgaven vil være at skrive et script (faktisk en konfigurationsfil), der automatisk genererer statiske sider fra et privat lager. Løsningen vil involvere funktionaliteten i et virtuelt miljø. Selve scriptet vil tilføje færdige sider til det offentlige lager.

Værktøjer til løsning

Værktøjer, som vi vil bruge til at løse problemet:

  • GitHub-handlinger;
  • Python3.7;
  • Pelikan;
  • Git;
  • GitHub-sider.

Løsning

Så efter at have stiftet bekendtskab med dokumentationen lidt og forstået, hvordan scripts til Actions er skrevet, blev det klart, at denne mekanisme helt vil løse det opståede problem. I skrivende stund skal du abonnere for at bruge denne funktionalitet. til beta-test!

GitHub-handlinger som CI/CD for et websted på en statisk generator og GitHub-sider
Beskrivelse af den nye funktionalitet af Github selv

At skrive et handlingsscript begynder med at oprette en navngivet fil i en mappe .github og dens undermappe workflows. Dette kan gøres enten manuelt eller fra editoren i fanen Handlinger på lagersiden.

GitHub-handlinger som CI/CD for et websted på en statisk generator og GitHub-sider
Eksempel på en tom scriptform

Jeg vil kort kommentere skemaet

name: CI    # название скрипта: будет отображаться во вкладке Actions

on: [push]  # действие, по которому запускается данный скрипт

jobs:       # роботы, которые будут выполняться
  build:    # сборка, которая..

    runs-on: ubuntu-latest      # ..будет запущена на основе этого образа

    steps:              # шаги которые будут проделаны после запуска образа
    - uses: actions/checkout@v1     # переход в самую актуальную ветку
    - name: Run a one-line script   # имя работы номер 1
      run: echo Hello, world!       # суть работы номер 1 (bash-команда записана в одну строку)
    - name: Run a multi-line script   # имя работы номер 2
      run: |                    # суть работы номер 2 (многострочная)
        echo Add other actions to build,
        echo test, and deploy your project.

Lad os skrive vores eget baseret på skabelonen:

0) Du kan også efterlade navnet "CI". Det er en smagssag.

1) Dernæst skal du vælge den handling/trigger, der vil starte scriptet, i vores tilfælde er dette det sædvanlige skub af en ny commit til repository.

on:
  push

2) Vi vil også efterlade det billede, som scriptet vil blive lanceret på grundlag af som eksempel, da Ubuntu er ganske tilfreds med den nødvendige funktionalitet. Ser på tilgængelige værktøjer det bliver klart, at dette kan være et hvilket som helst nødvendigt eller blot praktisk billede (eller en Docker-beholder baseret på det).

  build:
    runs-on: ubuntu-latest

3) I trinene vil vi først sætte miljøet op for at forberede hovedarbejdet.

3.1) gå til den filial, vi har brug for (standardtrin checkout):

- uses: actions/checkout@v1

3.2) installer Python:

    - name: Set up Python
      uses: actions/setup-python@v1
      with:
        python-version: 3.7

3.3) installer vores generators afhængigheder:

    - name: Install dependencies
      run: |
          python -m pip install --upgrade pip
          pip install -r requirements.txt

3.4) opret en mappe, hvor webstedets sider vil blive genereret:

   - name: Make output folder
      run: mkdir output

4) For at arbejdet på sitet skal være konsistent, nemlig ikke at slette tidligere ændringer og for at kunne tilføje ændringer til site repository uden konflikter, vil næste trin være at klone site repository hver gang:

   - name: Clone master branch
      run: git clone "https://${{ secrets.ACCESS_TOKEN }}@github.com/${GITHUB_ACTOR}/${GITHUB_ACTOR}.github.io.git" --branch master --single-branch ./output

Dette trin kalder systemvariabler:

  • variabel GITHUB_ACTOR GitHub installerer sig selv, og dette er brugernavnet, hvis fejl dette script blev lanceret;
  • variabel secrets.ACCESS_TOKEN dette genereres token til at administrere Github, kan vi videregive den som en miljøvariabel ved at indstille den i fanen Secrets vores lagerindstillinger. Bemærk venligst, at under genereringen vil tokenet blive leveret til os én gang, der vil ikke være yderligere adgang til det. Samt værdierne af Secrets-genstandene.

5) Lad os gå videre til at generere vores sider:

   - name: Generate static pages
      run: pelican content -o output -s publishconf.py

De parametre, der sendes til generatoren, er ansvarlige for den mappe, hvor de genererede filer vil blive sendt (-o output) og konfigurationsfilen, som vi bruger til at generere (-s publishconf.py; Du kan læse om tilgangen til at adskille den lokale konfiguration og konfigurationen til offentliggørelse i Pelican-dokumentationen).

Lad mig minde dig om, hvad der er i vores mappe output Site-lageret er allerede blevet klonet.

6) Lad os opsætte git og indeksere vores ændrede filer:

    - name: Set git config and add changes
      run: |
          git config --global user.email "${GITHUB_ACTOR}@https://users.noreply.github.com/"
          git config --global user.name "${GITHUB_ACTOR}"
          git add --all
      working-directory: ./output

På dette tidspunkt bruges en allerede kendt variabel, og arbejdsbiblioteket er angivet, hvor kommandoerne fra dette trin vil blive lanceret. Kommandoen til at gå til arbejdsbiblioteket ville ellers se ud som - cd output.

7) Lad os generere en commit-besked, begå ændringerne og skubbe dem ind i depotet. Således at commit ikke er forgæves og derfor ikke producerer en fejl i bash (outputresultatet er ikke 0) — lad os først tjekke, om det overhovedet er nødvendigt at forpligte sig og presse noget. For at gøre dette bruger vi kommandoen git diff-index --quiet --cached HEAD -- som udsendes til terminalen 0 hvis der ikke er nogen ændringer i forhold til den tidligere version af webstedet, og 1 der er sådanne ændringer. Derefter behandler vi resultatet af denne kommando. I informationen om udførelsen af ​​scriptet vil vi således registrere nyttige oplysninger om webstedets tilstand på dette trin i stedet for automatisk at gå ned og sende os en rapport om scriptnedbruddet.

Vi udfører også disse handlinger i vores bibliotek med færdige sider.

   - name: Push and send notification
      run: |
          COMMIT_MESSAGE="Update pages on $(date +'%Y-%m-%d %H:%M:%S')"
          git diff-index --quiet --cached HEAD -- && echo "No changes!" && exit 0 || echo $COMMIT_MESSAGE
          # Only if repo have changes
          git commit -m "${COMMIT_MESSAGE}"
          git push https://${{ secrets.ACCESS_TOKEN }}@github.com/${GITHUB_ACTOR}/${GITHUB_ACTOR}.github.io.git master
      working-directory: ./output

Outcome

Som et resultat giver et sådant script dig mulighed for ikke at tænke på at oprette statiske sider. Ved at tilføje ændringer direkte til et privat lager, hvad enten det er ved at arbejde med git fra et hvilket som helst system eller ved at oprette en fil via GitHub-webgrænsefladen, vil Actions gøre alt selv. Hvis scriptet går ned uventet, vil der blive sendt en meddelelse til din e-mail.

Fuld kode

Jeg forlader min arbejdsversion, hvor det sidste trin tilføjer at sende en meddelelse om, at en commit er blevet skubbet til hovedlageret.

De ovenfor beskrevne hemmeligheder bruges, hvor bot-tokenet og bruger-id'et, som beskeden skal sendes til, tilføjes.

name: Push content to the user's GitHub pages repository

on:
  push

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v1
    - name: Set up Python
      uses: actions/setup-python@v1
      with:
        python-version: 3.7
    - name: Install dependencies
      run: |
          python -m pip install --upgrade pip
          pip install -r requirements.txt
    - name: Make output folder
      run: mkdir output
    - name: Clone master branch
      run: git clone "https://${{ secrets.ACCESS_TOKEN }}@github.com/${GITHUB_ACTOR}/${GITHUB_ACTOR}.github.io.git" --branch master --single-branch ./output
    - name: Generate static pages
      run: pelican content -o output -s publishconf.py
    - name: Set git config and add changes
      run: |
          git config --global user.email "${GITHUB_ACTOR}@https://users.noreply.github.com/"
          git config --global user.name "${GITHUB_ACTOR}"
          git add --all
      working-directory: ./output
    - name: Push and send notification
      run: |
          COMMIT_MESSAGE="Update pages on $(date +'%Y-%m-%d %H:%M:%S')"
          git diff-index --quiet --cached HEAD -- && echo "No changes!" && exit 0 || echo $COMMIT_MESSAGE
          git commit -m "${COMMIT_MESSAGE}"
          git push https://${{ secrets.ACCESS_TOKEN }}@github.com/${GITHUB_ACTOR}/${GITHUB_ACTOR}.github.io.git master
          curl "https://api.telegram.org/bot${{ secrets.BOT_TOKEN }}/sendMessage?text=$COMMIT_MESSAGE %0ALook at ${GITHUB_ACTOR}.github.io %0ARepository%3A github.com/${GITHUB_ACTOR}/${GITHUB_ACTOR}.github.io&chat_id=${{ secrets.ADMIN_ID }}"
      working-directory: ./output

Skærmbilleder

GitHub-handlinger som CI/CD for et websted på en statisk generator og GitHub-sider
Resultatet af en af ​​kørslerne, der vises på fanen Handlinger i kildelageret

GitHub-handlinger som CI/CD for et websted på en statisk generator og GitHub-sider
Besked fra botten om færdiggørelsen af ​​scriptet

Nyttige links

Forstå handlinger
Syntaks for handlinger
Liste over udløsere
Muligheder for virtuelle miljøer
Github sider
Statisk generator liste

Kilde: www.habr.com

Tilføj en kommentar