Tu CI corre solo lo que falta

Lo que CI no vuelve a hacer Del check al código compilado.

hushrun: e2e skipped: this exact code passed 1 min ago (saves 16s)
hushrun: unit passed in 3s; reusing 98 tests saved about 1s; it won't run again on this code
hushrun: build: 226 of 360 crates reused (226 from the shared store), 134 built, saving about 2m 3s

• Un check que ya pasó

  Si una laptop, el sandbox de un agente o una corrida anterior pasaron este check en los mismos archivos, el job se lo salta y termina con 0, como un resultado exitoso. Eso cubre el push después de que tu agente pasó los checks, la corrida después de un merge y volver a correr un job inestable.

  Cómo funciona un salto en CI

• Pruebas que ya pasaron

  Cuando cambió el código de un check, CI puede dejar fuera las pruebas que ya pasaron en los archivos que leen, y correr las demás. Está apagado hasta que lo activas, check por check.

  Con qué funciona

• Código compilado

  En GitHub Actions, un job descarga lo que ya compiló el CI de tus ramas de confianza (ramas que lista un admin) en vez de compilarlo otra vez, y un pull request también reutiliza lo que compilaron sus corridas anteriores. CI nunca reutiliza lo que compiló una laptop. El almacén compartido está apagado hasta que un admin lo activa.

  Con qué funciona

Cada línea es la salida de hushrun tal como la muestra su documentación: un ejemplo de lo que dice, no una medición.

El CI de hushrun, contado Cada corrida, de logs públicos.

Configúralo en CI Un comando y luego un push.

En la raíz del repositorio, npx hushrun init envuelve tus checks donde están, en un script o en los archivos de CI. Los comandos siguen igual.

1. En GitHub Actions, haz commit y push

   init le da id-token: write a cada job que corre un check envuelto. El ID token del job prueba para qué repositorio corre, así que no hay ningún secreto que guardar. CI empieza a registrar.

2. En otro CI, guarda dos secretos

   GitLab CI, CircleCI, Buildkite, Jenkins y los demás usan un token de agente y una clave de máquina, guardados como secretos enmascarados.

3. Activa la reutilización de pruebas donde convenga

   Está apagada hasta que la activas, check por check. Empieza observando: todas las pruebas corren, y la corrida dice qué habría dejado fuera.

4. Pídele a un admin el almacén compartido

   Reutilizar código compilado entre máquinas está apagado en toda organización hasta que un admin lo activa, y entonces empieza observando. En CI funciona hoy en GitHub Actions.

Matrices, workflows reutilizables, colas de merge y reportes que lee un paso posterior: Set up CI, en inglés.

Preguntas sobre CI

¿Funciona con GitHub Actions?

Sí, sin ningún secreto que guardar: cada job que corre un check envuelto recibe un ID token de GitHub. Reutilizar código compilado del almacén compartido funciona en CI solo en GitHub Actions, por ahora.

¿Funciona con GitLab CI u otro CI?

Los checks se saltan en cualquier CI. GitLab CI, CircleCI, Buildkite, Jenkins y los demás usan un token de agente y una clave de máquina, guardados como secretos. GitLab CI todavía no usa el almacén compartido de código compilado. Other CI, en inglés.

¿Cuánto tiempo de CI me ahorra?

Lo que tardan los checks que vuelven a recibir los mismos archivos. Un salto ahorra lo que tardó el resultado de ese check, y el job igual arranca. Estima el ahorro, o pon tus números en la calculadora.

¿Es seguro saltarse un check en CI?

Un check se salta solo con los mismos archivos, comando y nombre de check que pasaron, firmado por la máquina de un miembro, uno de tus tokens de agente o el CI de tu repositorio. Un admin puede hacer que el CI de un repositorio se salte checks solo con los resultados del propio CI. Por qué es seguro

¿Cuánto cuesta?

Saltarse un check es gratis. CI necesita el servicio alojado de hushrun, gratis hasta 2,000 checks registrados al mes: los resultados guardados en una sola máquina están apagados en CI.