Accións de GitHub como CI/CD para un sitio nun xerador estático e páxinas de GitHub

Accións de GitHub como CI/CD para un sitio nun xerador estático e páxinas de GitHub

Despois de buscar un pouco a Habr, sorprendeume que se publicaran moi poucos artigos sobre o tema da función (beta) de GitHub: accións.

Parece que tal eufemismo pódese explicar polo feito de que a funcionalidade aínda está en proba, aínda que sexa "beta". Pero é unha característica útil da beta que permite que esta ferramenta se use en repositorios privados. Trátase de traballar con esta tecnoloxía da que falarei neste artigo.

Prehistoria

Se empezamos en orde, probablemente valga a pena mencionar que no proceso de busca dunha opción rápida, cómoda, sinxela e gratuíta para almacenar un sitio web persoal "Sobre min", tiven que pasar varias noites e peitear moitos artigos.

Algunhas persoas elixen aloxamento, outras un servidor na nube e as que non queren entender o traballo, a interacción e o pago de todo isto, como subir sitios estáticos a un repositorio, xa que agora pódese facer tanto en GitHub como en GitLab.

Por suposto, esta é a elección persoal de todos.

A miña última opción foi GitHub Pages.

Sobre as páxinas

Quen non sabe gh-pages - Esta é unha opción para almacenar documentación en forma de sitio web e ofrécese de xeito gratuíto e, ademais da documentación, tamén se propón almacenar sitios web persoais. Esta funcionalidade é proporcionada por GitHub a todos os usuarios e está dispoñible na configuración do repositorio.

O repositorio do proxecto usa unha rama gh-pages, para un sitio de usuario: un repositorio separado co nome username.github.io con fontes do sitio en master rama.

Podes ver máis detalles en documentación, pero permítanme observar que GitHub é sorprendentemente xeneroso ao permitir que calquera persoa ligue o seu propio dominio a un sitio deste tipo simplemente engadindo un ficheiro CNAME co nome de dominio e configurando o DNS do teu provedor de dominio nos servidores de GitHub.

Estou seguro de que hai moitos artigos aquí sobre como desenvolver un sitio deste tipo, polo que non vou falar máis adiante diso.

Aparición dun problema

O problema foi que ao usar un xerador estático, hai que escribir scripts adicionais e usar bibliotecas para simplificar o proceso de xeración de páxinas e cargalas no repositorio. Simplemente, se almacena as fontes nun repositorio privado separado, entón cada vez que hai algún cambio no sitio, foi necesario implementar o ambiente local para a posterior xeración de páxinas estáticas e publicación no repositorio principal do sitio.

Hai abundancia xeradores estáticos e todos teñen o mesmo problema. Estas accións levan demasiado tempo e esforzo e, en última instancia, retardan o traballo no sitio, especialmente despois de varias migracións do sistema operativo a outro ou de incidentes coa perda de datos nos discos duros. (este foi o caso no meu caso).

Recentemente, ben nunha notificación emerxente no sitio web ou nun boletín informativo de GitHub, notouse un CI/CD recén construído, que permitiu que estas accións se levaran a cabo cun mínimo esforzo.

Acerca dos xeradores de páxinas estáticas

Non centrarei especial atención neste subelemento, pero compartirei un par de teses ás que vin durante a selección e uso do seguinte:

1) elixe un xerador que se adapte á túa linguaxe de programación ou que sexa o máis claro posible. Cheguei a esta idea nun momento no que eu mesmo tiña que engadir algunha funcionalidade para que o sitio funcionase, engadir muletas para a súa maior estabilidade e automatización. Ademais, esta é unha boa razón para escribir vostede mesmo unha funcionalidade adicional en forma de complementos;

2) que xerador escoller é unha elección persoal, pero vale a pena ter en conta que para a inmersión inicial no traballo da funcionalidade das páxinas de GitHub, primeiro debes instalar Jekyll. Afortunadamente, permítelle xerar un sitio web desde fontes directamente no repositorio (Repetirei isto coa miña elección).

A miña elección do xerador baséase no primeiro punto. Pelícano que está escrito en Python substituíu facilmente a Jekyll, que é alleo para min (usouno case un ano). Como resultado, mesmo crear e editar artigos e traballar nun sitio web dá experiencia adicional nun idioma que me interesa.

__

Declaración de problemas

A tarefa principal será escribir un script (en realidade un ficheiro de configuración) que xeraría automaticamente páxinas estáticas desde un repositorio privado. A solución implicará a funcionalidade dun contorno virtual. O propio script engadirá páxinas preparadas ao repositorio público.

Ferramentas para a solución

Ferramentas que utilizaremos para resolver o problema:

  • Accións de GitHub;
  • Python 3.7;
  • Pelicano;
  • Git;
  • Páxinas de GitHub.

A solución

Entón, despois de familiarizarse un pouco coa documentación e comprender como se escriben os guións para Actions, quedou claro que este mecanismo resolverá completamente o problema xurdido. No momento de escribir este artigo, debes subscribirte para usar esta funcionalidade. para probas beta!

Accións de GitHub como CI/CD para un sitio nun xerador estático e páxinas de GitHub
Descrición da nova funcionalidade polo propio Github

A escritura dun script de accións comeza creando un ficheiro con nome nun cartafol .github e o seu subcartafol workflows. Isto pódese facer manualmente ou desde o editor na pestana Accións da páxina do repositorio.

Accións de GitHub como CI/CD para un sitio nun xerador estático e páxinas de GitHub
Exemplo de formulario de guión en branco

Vou comentar brevemente o formulario

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.

Escribamos a nosa baseada no modelo:

0) Tamén pode deixar o nome "CI". É cuestión de gustos.

1) A continuación, cómpre seleccionar a acción/disparador que lanzará o script, no noso caso este é o empuxe habitual dun novo commit no repositorio.

on:
  push

2) Tamén deixaremos a imaxe en base á cal se lanzará o script como exemplo, xa que Ubuntu está bastante satisfeito coa funcionalidade necesaria. Mirando ferramentas dispoñibles queda claro que esta pode ser calquera imaxe necesaria ou simplemente conveniente (ou un contedor Docker baseado nela).

  build:
    runs-on: ubuntu-latest

3) Nos pasos, primeiro configuraremos o ambiente para preparar o traballo principal.

3.1) vai á rama que necesitamos (paso estándar checkout):

- uses: actions/checkout@v1

3.2) instalar Python:

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

3.3) instalar as dependencias do noso xerador:

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

3.4) cree un directorio no que se xerarán as páxinas do sitio:

   - name: Make output folder
      run: mkdir output

4) Para que o traballo no sitio sexa coherente, é dicir, para non eliminar os cambios anteriores e para poder engadir cambios ao repositorio do sitio sen conflitos, o seguinte paso será clonar o repositorio do sitio cada vez:

   - 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

Este paso chama as variables do sistema:

  • variable GITHUB_ACTOR GitHub instálase, e este é o nome de usuario por culpa do cal se lanzou este script;
  • variable secrets.ACCESS_TOKEN isto xérase token para a xestión de Github, podemos pasalo como unha variable de ambiente configurandoo na pestana Secrets a configuración do noso repositorio. Ten en conta que durante a xeración o token será proporcionado unha vez, non haberá máis acceso a el. Así como os valores dos elementos Segredos.

5) Pasemos á xeración das nosas páxinas:

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

Os parámetros pasados ​​ao xerador son responsables do directorio onde se enviarán os ficheiros xerados (-o output) e o ficheiro de configuración que usamos para xerar (-s publishconf.py; Podes ler sobre o enfoque para separar a configuración local e a configuración para a súa publicación na documentación de Pelican).

Permíteme recordarche o que hai no noso cartafol output O repositorio do sitio xa foi clonado.

6) Imos configurar git e indexar os nosos ficheiros modificados:

    - 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

Neste punto, utilízase unha variable xa coñecida e indícase o directorio de traballo no que se lanzarán os comandos deste paso. O comando para ir ao directorio de traballo semellaría doutro xeito - cd output.

7) Xeramos unha mensaxe de confirmación, cometemos os cambios e empuxémolos no repositorio. Para que a confirmación non sexa en balde e, polo tanto, non produza un erro en bash (o resultado de saída non é 0) - primeiro, comprobamos se é necesario comprometer e impulsar algo. Para iso utilizamos o comando git diff-index --quiet --cached HEAD -- que sairá ao terminal 0 se non hai cambios en relación coa versión anterior do sitio, e 1 hai tales cambios. Despois procesamos o resultado deste comando. Así, na información sobre a execución do script, rexistraremos información útil sobre o estado do sitio nesta fase, en lugar de fallar automaticamente e enviarnos un informe sobre o fallo do script.

Tamén realizamos estas accións no noso directorio con páxinas preparadas.

   - 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

Resultado

Como resultado, tal script permítelle non pensar en crear páxinas estáticas. Ao engadir cambios directamente a un repositorio privado, xa sexa traballando con git desde calquera sistema ou creando un ficheiro a través da interface web de GitHub, Actions fará todo por si mesmo. Se o script falla de forma inesperada, enviarase unha notificación ao teu correo electrónico.

Código completo

Deixarei a miña versión de traballo, na que o último paso engade o envío dunha notificación de que se enviou unha confirmación ao repositorio principal.

Utilízanse os segredos descritos anteriormente, onde se engaden o token do bot e o ID de usuario ao que se debe enviar a mensaxe.

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

Imaxes

Accións de GitHub como CI/CD para un sitio nun xerador estático e páxinas de GitHub
O resultado dunha das execucións que se mostra na pestana Accións do repositorio de orixe

Accións de GitHub como CI/CD para un sitio nun xerador estático e páxinas de GitHub
Mensaxe do bot sobre a finalización do guión

Ligazóns útiles

Comprensión de accións
Sintaxe de accións
Lista de disparadores
Opcións para contornas virtuais
Páxinas Github
Lista de xeradores estáticos

Fonte: www.habr.com

Engadir un comentario