Ir al contenido

Generar la configuración

Responde cómo es tu despliegue y esto escribe las tres cosas que lo ponen en marcha: el config.yaml que lee una ejecución normal, el comando que lo ejecuta y el paso que un workflow le da a la Action compuesta. Las tres salen de un mismo conjunto de respuestas, y ninguna pide una credencial.

Los controles no son una copia de los ajustes. cmd/gen_config exporta los propios tipos de internal/config a un fichero que la página lee, incluido el valor por omisión al que se resuelve cada clave, que mide validando una sonda en vez de repetir un número. make check-config-options falla cuando ese fichero deja de ser lo que produce el código, en la suite de análisis y en CI, así que el formulario no puede ofrecer un ajuste que el binario no tiene ni perderse uno que sí tiene.

La dirección contraria también se comprueba, y su límite conviene decirlo en voz alta. Las configuraciones que este formulario escribe para los conjuntos de respuestas de internal/config/testdata/config-cases.json pasan por el parser real en las propias pruebas de internal/config, incluidas las formas que han hecho tropezar a alguien: una cadencia por familia bajo every.families, un include_private desactivado, un destino cuyas credenciales son referencias ${VAR}, una ejecución de solo tarjeta sin ningún destino y respuestas que se espera que el parser rechace. Esos casos los genera el módulo que ejecuta esta página, así que no pueden ser una copia suya, y cada rama de ese módulo que puede cambiar lo que escribe tiene uno. Lo que el corpus no demuestra es el comportamiento que ningún conjunto de respuestas produce, y por eso el fichero que lo define enumera lo que no puede cubrir y por qué.

Qué permite el formulario y rechaza el parser

Sección titulada «Qué permite el formulario y rechaza el parser»

Un formulario es un formulario: un destino es una casilla y las claves sin las que no se resuelve no lo son, así que unos pocos clics bastan para escribir un fichero que muere al arrancar. La página avisa de aquellas que su propia lista generada de ajustes puede ver, encima de las salidas, y nombra el resto aquí. Rechazar el resto en el formulario obligaría a guardar en esta página una segunda copia de una regla del parser, que es justo la desviación que todo este montaje existe para evitar.

  • Un destino activado con una clave obligatoria vacía se rechaza con nombre y ejemplo: sinks.loki: url is required, for example http://loki:3100. De esta avisa el formulario.
  • Un campo de credencial respondido con la credencial en vez de con el nombre de una variable de entorno se queda fuera del fichero. De esta avisa el formulario.
  • Un fichero sin nada dentro se rechaza: the file is empty.
  • No indicar ninguna cuenta se rechaza: targets: set at least one of user, orgs or repos.
  • heartbeat: 0 se rechaza: tiene que ser positivo, y dejar la clave fuera es la forma de que el tic del bucle se derive solo.
  • Una cadencia que no es una duración se rechaza donde se usa: every.families.repo: time: invalid duration "soon".
  • sinks.elasticsearch.api_key rellenado a la vez que sinks.elasticsearch.username se rechaza: sinks.elasticsearch: set either api_key or username and password, not both.
  • Escribir - en sinks.sql.path con sinks.stdout activado se acepta y deja dos escritores sobre el mismo flujo; elige uno.
La cuenta y su API5

Leer sobre estos ajustes

Qué recoger7

Leer sobre estos ajustes

Dónde van los puntos50

Leer sobre estos ajustes

influxdb
prometheus
otlp
loki
file
telegraf
graphite
sql
elasticsearch
Cada cuánto3

Leer sobre estos ajustes

every.groups
every.families
El registro de la ejecución5

Leer sobre estos ajustes

La ejecución4

Leer sobre estos ajustes

groups

config.yaml

Guárdalo junto al binario, o en la ruta que pases a -config, y ejecútalo con el comando de abajo.

github:
  token: ${GITHUB_TOKEN}
targets:
  user: octocat
sinks:
  stdout: true

El comando que lo ejecuta

ghchronicle -config config.yaml -once

Paso del workflow

Pega esto en los steps de un job. El token es un secreto del repositorio, nunca un valor en el fichero.

- uses: jmrplens/ghchronicle@v1
  with:
    token: ${{ secrets.GHCHRONICLE_TOKEN }}
    config: .github/ghchronicle.yaml

Un campo de credencial pide el NOMBRE de una variable de entorno, y el fichero recibe ${NOMBRE}, que el binario expande al arrancar. Una respuesta que no es un nombre de variable se deja fuera del fichero en vez de escribirse en él. El campo de cabeceras es la excepción: es texto libre y lo que se escriba ahí se escribe tal cual.

No hay un único comando, y por eso el formulario lo escribe. Una configuración que nombra un destino se ejecuta con -once. Una que no nombra ninguno la rechaza -once, con el parser pidiendo un destino que no querías, así que se ejecuta con -card-only y una ruta para la tarjeta. El comando de arriba cambia con las respuestas, y el paso también.

El paso va en los steps: de un job de workflow. Las respuestas que ningún input transporta hacen que el paso lea el fichero, y el fichero hay que publicarlo en la ruta que nombra el paso; las respuestas que los cuatro inputs sí transportan se escriben en el propio paso, y entonces no hace falta fichero ninguno. Un paso sin fichero que no nombra destino es una ejecución de tarjeta, mode: card con una ruta en card:, porque eso es lo único que la Action convierte en -card-only.

Las dos salidas tienen valores por omisión opuestos en un ajuste, y el paso se escribe de forma que diga cuál te toca. include-private está desactivado salvo que lo pidas, porque una tarjeta que cuenta repositorios privados publica sus nombres en un README público; targets.include_private está activado salvo que digas lo contrario, porque el token ya llega a ellos. Por eso un paso sin fichero siempre escribe el input en vez de dejarlo en un valor por omisión que significa lo contrario que el fichero de al lado. Mira GitHub Actions para el workflow que lo rodea, y el token para lo que el secreto tiene que poder hacer.