ProHoster > Blog > Administración > 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!
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.
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.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:
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.
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:
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.