Ir al contenido

Formas de instalar

Un único binario estático sin dependencias en tiempo de ejecución. Cómo llega a la máquina es la única decisión, y se deriva de dónde quieras que corra.

Las releases llevan binarios para Linux, macOS y Windows, en amd64 y arm64. Las tres páginas de abajo son el mismo recorrido para cada sistema, hasta el final: qué archivo, cómo comprobarlo, dónde va el binario, cómo ejecutarlo una vez y cómo dejarlo corriendo cuando termines de mirarlo.

Ventana de terminal
curl -fsSL https://raw.githubusercontent.com/jmrplens/ghchronicle/main/install.sh | bash

En Windows, desde PowerShell:

Ventana de terminal
irm https://raw.githubusercontent.com/jmrplens/ghchronicle/main/install.ps1 | iex

Cualquiera de las dos deduce la plataforma, coge la release más nueva y se niega a instalar nada cuya suma de verificación no sea la que publicó la release.

El colector envía por push a todos los almacenes que soporta, así que no hace falta que sea alcanzable desde ningún sitio. Necesita alcanzar GitHub y alcanzar sus bases de datos. Esa es la única restricción, y es lo que hace viables las cuatro opciones. Tres de las cuatro quieren una máquina propia: systemd, Docker y cron. GitHub Actions es la que no. Las páginas por sistema de arriba son donde vive el planificador, uno por sistema: systemd o cron en Linux, launchd en macOS y una tarea programada en Windows.

OrdenHace
ghchronicle -config config.yamlCorre indefinidamente, cada familia con su cadencia
ghchronicle -config config.yaml -onceUna pasada y termina
ghchronicle -config config.yaml -backfillRecorre cada superficie hasta el final, esperando al límite de peticiones

Más dos que no escriben nada: -list imprime los repositorios en alcance, y -card ... -card-only dibuja el SVG sin tocar una base de datos.

Una versión nueva se instala encima de la anterior como se instaló esa, y la configuración y el estado pasan tal cual. Cómo son las primeras horas tras ella, de la 2.5.x a la 2.6.x y a la 2.6.1, está en actualizar.