След като прегледах малко Habr, бях изненадан, че са публикувани много малко статии по темата за (бета) функцията на GitHub - Действия.

Изглежда, че подобно подценяване може да се обясни с факта, че функционалността все още е в процес на тестване, макар и „бета“. Но това е полезна функция на бета версията, която позволява този инструмент да се използва в частни хранилища. Именно за работата с тази технология ще говоря в тази статия.

праистория

Ако започнем по ред, вероятно си струва да споменем, че в процеса на търсене на бърза, удобна, лесна и безплатна опция за съхраняване на личен уебсайт „За мен“ трябваше да прекарам няколко нощи и да прегледам много статии.

Някои хора избират хостинг, други облачен сървър, а тези, които не искат да разбират работата, взаимодействието и плащането за всичко това, харесват качването на статични сайтове в хранилище, тъй като сега това може да се направи както на GitHub, така и на GitLab.

Разбира се, това е личен избор на всеки.

Последният ми избор беше GitHub Pages.

Относно страниците

Кой не знае gh-pages - това е възможност за съхраняване на документация под формата на уебсайт и се предоставя безплатно, като освен документация се предлага съхраняване и на лични сайтове. Тази функционалност се предоставя от GitHub на всички потребители и е достъпна в настройките на хранилището.

Хранилището на проекта използва клон gh-pages, за потребителски сайт - отделно хранилище с името username.github.io с източници на сайта в master клон.

Можете да видите повече подробности в документация, но нека само да отбележа, че GitHub е изненадващо щедър, като позволява на всеки да свърже свой собствен домейн към такъв сайт, като просто добави файл CNAME с името на домейна и настройване на DNS на вашия доставчик на домейн на сървърите на GitHub.

Сигурен съм, че тук има много статии за това как да се разработи такъв сайт, така че няма да говоря за това по-нататък.

Възникване на проблем

Проблемът беше, че когато се използва статичен генератор, има нужда да се пишат допълнителни скриптове и да се използват библиотеки, за да се опрости процеса на генериране на страници и зареждането им в хранилището. Просто, ако съхранявате източниците в отделно частно хранилище, тогава всеки път, когато има някаква промяна на сайта, е необходимо да разположите локалната среда за последващо генериране на статични страници и публикуване в основното хранилище на сайта.

Има изобилие статични генератори и всички имат един и същ проблем. Тези действия отнемат твърде много време и усилия и в крайна сметка забавят работата на сайта, особено след няколко миграции от ОС към ОС или инциденти със загуба на данни на твърди дискове (в моя случай беше така).

Съвсем наскоро, или в изскачащо известие на уебсайта, или в бюлетин от GitHub, беше забелязан новоизграден CI/CD, който позволи тези действия да бъдат извършени с минимални усилия.

Относно генераторите на статични страници

Няма да насочвам специално внимание към тази подпозиция, но ще споделя няколко тези, до които стигнах при избора и използването на следното:

1) изберете генератор, който отговаря на вашия език за програмиране или такъв, който е възможно най-ясен. До тази идея стигнах в момент, когато аз самият трябваше да добавя някаква функционалност, за да работи сайта, да добавя патерици за неговата по-голяма стабилност и автоматизация. В допълнение, това е добра причина сами да напишете допълнителна функционалност под формата на добавки;

2) кой генератор да изберете е личен избор, но си струва да се има предвид, че за първоначалното потапяне в работата на функционалността на GitHub Pages, първо трябва да инсталирате Джекил. За щастие ви позволява да генерирате уебсайт от източници директно в хранилището (Ще повторя това с моя избор).

Моят избор на генератор се основава на първата точка. пеликан който е написан на Python лесно замени Jekyll, който ми е чужд (използвах го почти година). В резултат дори създаването и редактирането на статии и работата по уебсайт дава допълнително изживяване на език, който е интересен за мен.

__

Проблем изявление

Основната задача ще бъде да се напише скрипт (всъщност конфигурационен файл), който автоматично да генерира статични страници от частно хранилище. Решението ще включва функционалност на виртуална среда. Самият скрипт ще добави готови страници към публичното хранилище.

Инструменти за решение

Инструменти, които ще използваме за решаване на проблема:

• GitHub действия;
• Python3.7;
• Пеликан;
• Git;
• Страници на GitHub.

Решението

И така, след като се запознах малко с документацията и разбрах как се пишат скриптове за действия, стана ясно, че този механизъм ще реши напълно възникналия проблем. Към момента на писане трябва да се абонирате, за да използвате тази функционалност. за бета тестване!

Описание на новата функционалност от самия Github

Писането на скрипт за действия започва със създаване на именуван файл в папка .github и неговата подпапка workflows. Това може да се направи ръчно или от редактора в раздела Действия на страницата на хранилището.

Пример за празна форма на скрипт

Ще коментирам накратко формата

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.

Нека напишем нашите собствени въз основа на шаблона:

0) Можете също да оставите името „CI“. Въпрос на вкус.

1) След това трябва да изберете действието/тригера, който ще стартира скрипта, в нашия случай това е обичайното натискане на нов ангажимент към хранилището.

on:
  push

2) Ще оставим и изображението, на базата на което ще се стартира скриптът като пример, тъй като Ubuntu е доста доволен от необходимата функционалност. Гледам към налични инструменти става ясно, че това може да бъде всяко необходимо или просто удобно изображение (или Docker контейнер, базиран на него).

  build:
    runs-on: ubuntu-latest

3) В стъпките първо ще настроим средата, за да се подготвим за основната работа.

3.1) отидете до клона, от който се нуждаем (стандартна стъпка checkout):

- uses: actions/checkout@v1

3.2) инсталирайте Python:

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

3.3) инсталирайте зависимостите на нашия генератор:

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

3.4) създайте директория, в която ще се генерират страниците на сайта:

   - name: Make output folder
      run: mkdir output

4) За да бъде работата на сайта последователна, а именно да не се изтриват предишни промени и да можете да добавяте промени в хранилището на сайта без конфликти, следващата стъпка ще бъде всеки път да клонирате хранилището на сайта:

   - 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

Тази стъпка извиква системни променливи:

• променлива GITHUB_ACTOR GitHub се инсталира сам и това е потребителското име, по чиято вина е стартиран този скрипт;
• променлива secrets.ACCESS_TOKEN това се генерира токен за управление на Github, можем да го предадем като променлива на средата, като го зададем в раздела Secrets настройките на нашето хранилище. Моля, имайте предвид, че по време на генерирането токенът ще ни бъде предоставен веднъж, няма да има по-нататъшен достъп до него. Както и стойностите на елементите Secrets.

5) Нека да преминем към генерирането на нашите страници:

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

Параметрите, предадени на генератора, отговарят за директорията, в която ще бъдат изпратени генерираните файлове (-o output) и конфигурационния файл, който използваме за генериране (-s publishconf.py; Можете да прочетете за подхода за разделяне на локалната конфигурация и конфигурацията за публикуване в документацията на Pelican).

Нека ви напомня какво има в нашата папка output Хранилището на сайта вече е клонирано.

6) Нека настроим git и индексираме нашите променени файлове:

    - 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

В този момент се използва вече известна променлива и се посочва работната директория, в която ще се стартират командите от тази стъпка. Командата за отиване в работната директория иначе би изглеждала така - cd output.

7) Нека генерираме съобщение за ангажиране, ангажираме промените и ги натискаме в хранилището. Така че ангажиментът не е напразен и следователно не създава грешка в bash (изходният резултат не е 0) — първо, нека проверим дали изобщо е необходимо да се ангажираме и натискаме нещо. За целта използваме командата git diff-index --quiet --cached HEAD -- който ще изведе към терминала 0 ако няма промени спрямо предишната версия на сайта и 1 има такива промени. След това обработваме резултата от тази команда. Така в информацията за изпълнението на скрипта ще записваме полезна информация за състоянието на сайта на този етап, вместо автоматично да се срива и да ни изпраща доклад за срива на скрипта.

Извършваме тези действия и в нашата директория с готови страници.

   - 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

Резултат

В резултат на това такъв скрипт ви позволява да не мислите за създаване на статични страници. Чрез добавяне на промени директно към частно хранилище, независимо дали чрез работа с git от всяка система или създаване на файл през уеб интерфейса на GitHub, Actions ще направят всичко сами. Ако скриптът се срине неочаквано, на вашия имейл ще бъде изпратено известие.

Пълен код

Ще оставя работната си версия, в която последната стъпка добавя изпращане на известие, че ангажиментът е изпратен към главното хранилище.

Използват се описаните по-горе Secrets, където се добавят токенът на бота и потребителският идентификатор, на когото трябва да се изпрати съобщението.

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

Снимки на екрана

Резултатът от едно от изпълненията, показани в раздела Действия на изходното хранилище

Съобщение от бота за завършване на скрипта

Полезни връзки

Разбиране на действията
Синтаксис на действията
Списък на тригерите
Опции за виртуални среди
Github страници
Списък на статичен генератор

Източник: www.habr.com