Etter å ha undersøkt Habr litt, ble jeg overrasket over at svært få artikler har blitt publisert om temaet GitHubs (beta) funksjon - Handlinger.

Det ser ut til at en slik underdrivelse kan forklares med det faktum at funksjonaliteten fortsatt er i testing, om enn "beta". Men det er en nyttig funksjon i betaen som gjør at dette verktøyet kan brukes i private depoter. Det handler om å jobbe med denne teknologien som jeg skal snakke om i denne artikkelen.

forhistorie

Hvis vi starter i rekkefølge, er det sannsynligvis verdt å nevne at i prosessen med å søke etter et raskt, praktisk, enkelt og gratis alternativ for å lagre et personlig "Om meg"-nettsted, måtte jeg tilbringe flere netter og gre gjennom mange artikler.

Noen velger hosting, andre en skyserver, og de som ikke ønsker å forstå arbeidet, interaksjonen og betalingen for alt dette som å laste opp statiske nettsteder til et depot, siden dette nå kan gjøres både på GitHub og GitLab .

Dette er selvfølgelig alles personlige valg.

Mitt siste valg var GitHub Pages.

Om sider

Hvem vet ikke gh-pages - dette er en mulighet for lagring av dokumentasjon i form av en nettside og den leveres gratis, og i tillegg til dokumentasjon foreslås det også å lagre personlige nettsider. Denne funksjonaliteten leveres av GitHub til alle brukere og er tilgjengelig i depotinnstillingene.

Prosjektdepotet bruker en filial gh-pages, for en brukerside - et eget depot med navnet username.github.io med nettstedskilder i master gren.

Du kan se flere detaljer i dokumentasjon, men la meg bare merke at GitHub er overraskende sjenerøs når det gjelder å tillate hvem som helst å koble sitt eget domene til et slikt nettsted ved å legge til en fil CNAME med domenenavnet og oppsett av DNS til domeneleverandøren din på GitHub-serverne.

Jeg er sikker på at det er mange artikler her om hvordan man utvikler et slikt nettsted, så det er ikke det jeg skal snakke om videre.

Problem som oppstår

Problemet var at når du bruker en statisk generator, er det behov for å skrive flere skript og bruke biblioteker for å forenkle prosessen med å generere sider og laste dem inn i depotet. Ganske enkelt, hvis du lagrer kildene i et eget privat depot, så hver gang det er noen endring på nettstedet, var det nødvendig å distribuere det lokale miljøet for den påfølgende generasjonen av statiske sider og publisering i hovednettstedet.

Det er en overflod statiske generatorer og de har alle samme problem. Disse handlingene tar for mye tid og krefter, og reduserer til slutt arbeidet på nettstedet, spesielt etter flere migreringer fra OS til OS eller hendelser med tap av data på harddisker (dette var tilfellet i mitt tilfelle).

Bare nylig, enten i en popup-melding på nettsiden eller i et nyhetsbrev fra GitHub, ble det lagt merke til en nybygd CI/CD, som gjorde det mulig å utføre disse handlingene med minimal innsats.

Om statiske sidegeneratorer

Jeg vil ikke fokusere spesielt på dette underelementet, men jeg vil dele et par avhandlinger som jeg kom til under utvelgelsen og bruken av følgende:

1) velg en generator som passer ditt programmeringsspråk, eller en som er så tydelig som mulig. Jeg kom til denne ideen på et tidspunkt da jeg selv måtte legge til noe funksjonalitet for at siden skulle fungere, legge til krykker for større stabilitet og automatisering. I tillegg er dette en god grunn til å skrive tilleggsfunksjonalitet selv i form av plugins;

2) hvilken generator du skal velge er et personlig valg, men det er verdt å vurdere at for den første fordypningen i arbeidet med GitHub Pages-funksjonaliteten, må du først installere Jekyll. Heldigvis lar den deg generere et nettsted fra kilder direkte i depotet (Jeg vil gjenta dette med mitt valg).

Mitt valg av generator er basert på det første punktet. Pelikan som er skrevet i Python erstattet lett Jekyll, som er fremmed for meg (brukte den i nesten et år). Som et resultat gir selv å lage og redigere artikler og jobbe med et nettsted ekstra erfaring på et språk som er interessant for meg.

Formulering av problemet

Hovedoppgaven vil være å skrive et skript (faktisk en konfigurasjonsfil) som automatisk vil generere statiske sider fra et privat depot. Løsningen vil innebære funksjonaliteten til et virtuelt miljø. Selve skriptet vil legge til ferdige sider til det offentlige depotet.

Verktøy for løsning

Verktøy vi skal bruke for å løse problemet:

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

Løsningen

Så etter å ha blitt litt kjent med dokumentasjonen og forstått hvordan skript for handlinger er skrevet, ble det klart at denne mekanismen helt vil løse problemet som har oppstått. I skrivende stund må du abonnere for å bruke denne funksjonaliteten. for betatesting!

Beskrivelse av den nye funksjonaliteten av Github selv

Å skrive et handlingsskript begynner med å lage en navngitt fil i en mappe .github og dens undermappe workflows. Dette kan gjøres enten manuelt eller fra editoren i fanen Handlinger på repository-siden.

Eksempel på et tomt skriptskjema

Jeg vil kort kommentere skjemaet

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.

La oss skrive vår egen basert på malen:

0) Du kan også legge igjen navnet "CI". Det er en smakssak.

1) Deretter må du velge handlingen/triggeren som vil starte skriptet, i vårt tilfelle er dette det vanlige trykket av en ny commit til depotet.

on:
  push

2) Vi vil også forlate bildet som skriptet vil bli lansert på grunnlag av som et eksempel, siden Ubuntu er ganske fornøyd med den nødvendige funksjonaliteten. Ser på tilgjengelige verktøy det blir klart at dette kan være et hvilket som helst nødvendig eller ganske enkelt praktisk bilde (eller en Docker-beholder basert på det).

  build:
    runs-on: ubuntu-latest

3) I trinnene vil vi først sette opp miljøet for å forberede hovedarbeidet.

3.1) gå til grenen vi trenger (standardtrinn 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 avhengighetene til generatoren vår:

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

3.4) opprette en katalog der nettstedsidene vil bli generert:

   - name: Make output folder
      run: mkdir output

4) For at arbeidet på siden skal være konsistent, nemlig ikke å slette tidligere endringer og for å kunne legge til endringer i sidedepotet uten konflikter, vil neste steg være å klone siterepositoriet 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 trinnet kaller systemvariabler:

variabel GITHUB_ACTOR GitHub installerer seg selv, og dette er brukernavnet hvis feil dette skriptet ble lansert;
variabel secrets.ACCESS_TOKEN dette genereres token for å administrere Github, kan vi sende den som en miljøvariabel ved å sette den i fanen Secrets våre lagerinnstillinger. Vær oppmerksom på at under generering vil tokenet bli gitt til oss én gang, det vil ikke være ytterligere tilgang til det. I tillegg til verdiene til Secrets-gjenstandene.

5) La oss gå videre til å generere sidene våre:

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

Parametrene som sendes til generatoren er ansvarlige for katalogen hvor de genererte filene skal sendes (-o output) og konfigurasjonsfilen som vi bruker til å generere (-s publishconf.py; Du kan lese om tilnærmingen til å skille den lokale konfigurasjonen og konfigurasjonen for publisering i Pelican-dokumentasjonen).

La meg minne deg på hva som er i mappen vår output Nettstedlageret er allerede klonet.

6) La oss sette opp git og indeksere våre endrede 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 tidspunktet brukes en allerede kjent variabel og arbeidskatalogen er indikert der kommandoene fra dette trinnet vil bli lansert. Kommandoen for å gå til arbeidskatalogen ville ellers se slik ut - cd output.

7) La oss generere en forpliktelsesmelding, forplikte endringene og skyve dem inn i depotet. Slik at commit ikke er forgjeves og derfor ikke produserer en feil i bash (utgangsresultatet er det ikke 0) — La oss først sjekke om det er nødvendig å forplikte seg og presse noe i det hele tatt. For å gjøre dette bruker vi kommandoen git diff-index --quiet --cached HEAD -- som vil sende ut til terminalen 0 hvis det ikke er noen endringer i forhold til den forrige versjonen av nettstedet, og 1 det er slike endringer. Deretter behandler vi resultatet av denne kommandoen. I informasjonen om utførelse av skriptet vil vi derfor registrere nyttig informasjon om tilstanden til nettstedet på dette stadiet, i stedet for å automatisk krasje og sende oss en rapport om skriptkrasj.

Vi utfører også disse handlingene i vår katalog med ferdige 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

Resultat

Som et resultat lar et slikt skript deg ikke tenke på å lage statiske sider. Ved å legge til endringer direkte i et privat depot, enten ved å jobbe med git fra et hvilket som helst system eller lage en fil gjennom GitHub-nettgrensesnittet, vil Actions gjøre alt selv. Hvis skriptet krasjer uventet, vil et varsel bli sendt til e-posten din.

Full kode

Jeg forlater arbeidsversjonen min, der det siste trinnet legger til å sende et varsel om at en forpliktelse har blitt presset til hovedlageret.

De ovenfor beskrevne hemmelighetene brukes, hvor bot-tokenet og bruker-IDen som meldingen må sendes til legges til.

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

Skjermbilder

Resultatet av en av kjøringene som vises i fanen Handlinger i kildelageret

Melding fra boten om fullføringen av skriptet

Nyttige lenker

Forstå handlinger
Handlingssyntaks
Liste over utløsere
Alternativer for virtuelle miljøer
Github-sider
Liste over statiske generatorer

Kilde: www.habr.com

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