La primera ejecución de un smoke test atrapó un bug real

Por qué un schedule, si el CI ya existe

Las pruebas unitarias ejercitan tus supuestos; un schedule ejercita los del mundo. Las APIs de los proveedores cambian debajo de ti, y un escaneo semanal de solo lectura con credenciales reales detecta problemas de alcance y deriva de credenciales antes de que un despliegue dependa de ellos.

El primer disparo reportó el adaptador de GitHub como inalcanzable. La credencial que usaba era el propio GITHUB_TOKEN del workflow, acuñado por GitHub segundos antes.

El bug: validez comprobada a través de la identidad

El chequeo de salud del adaptador llamaba a GET /user. Para un personal access token eso funciona bien. Pero el token que GitHub Actions inyecta en un workflow es un token de instalación de app, limitado al repositorio, sin identidad de usuario alguna. Para toda esa clase de credencial, /user responde 403.

# user PAT                          # Actions installation token
GET /user                           GET /user
200 OK {"login": "you"}             403 Resource not accessible
                                        by integration

GET /rate_limit                     GET /rate_limit
200 OK                              200 OK

Así que el chequeo estaba comprobando en realidad si el token pertenecía a un humano. Todo pipeline de CI, el nuestro incluido, se autentica exactamente con la clase de credencial que rechazaba.

Nuestra suite unitaria no podía haber atrapado esto: los mocks respondían /user tal como asumíamos que GitHub lo haría. Solo un token real de un workflow real podía contradecir el supuesto.

El arreglo, y la línea que se negó a cruzar

El chequeo reparado prueba la validez donde la identidad no se asume. GET /rate_limit responde 200 para cualquier token vivo, de usuario o de instalación. Cuando /user funciona, el adaptador reporta la identidad humana como antes; cuando responde 403, recurre a la prueba de rate limit y reporta lo que la credencial realmente es: un token de instalación de app, limitado al repo, sin identidad de usuario.

Una propiedad importaba más que la comodidad: si ambas pruebas fallan, el adaptador sigue negándose. Un fallback que convierte dos fallos en un aprobado no es un fallback, es una puerta abierta. El arreglo se publicó como launchops-adapters 0.12.0 el mismo día. La re-ejecución lo verificó contra el mismo token real que encontró el bug: ok, github, 366 ms, cuatro grupos de recursos leídos.

Qué se generaliza

• Validez e identidad son preguntas distintas. Prueba la vitalidad en un endpoint que responda para toda clase de credencial que aceptes; reporta la identidad por separado cuando exista.
• Un smoke programado pequeño con credenciales reales, semanal y de solo lectura, atrapa lo que los mocks estructuralmente no pueden.
• Cuando añadas un fallback, decide primero qué debe hacer el fallo total. Aquí sigue negándose.

Fuentes: el arreglo está publicado como @enterprise-skills/launchops-adapters · cómo funcionan nuestras puertas de lanzamiento · La guía de listo para producción