Qué pasa
Tras cortar un release (ej. 0.10.2, #228), el step de back-merge automático en release-please.yml corre e intenta pushear main → dev directo, pero dev está protegido → falla:
remote: error: GH006: Protected branch update failed for refs/heads/dev.
remote: - Changes must be made through a pull request.
remote: - 3 of 3 required status checks are in progress.
! [remote rejected] HEAD -> dev (protected branch hook declined)
##[error]Process completed with exit code 1.
Resultado: el back-merge no ocurre solo; hay que hacerlo a mano vía PR (lo hice en #241 para 0.10.2). La automatización queda en rojo en cada release.
Por qué importa
Sin back-merge, dev queda atrás de main en el bump de versión + CHANGELOG → drift de versión/uv.lock que confunde al próximo release-please. Hoy depende de que alguien recuerde hacer el PR manual. Encaja con el plan de "convertir fricciones en guardarraíles" (confianza para soltar/dormir).
Opciones (decisión de infra/seguridad del PO)
- El workflow crea un PR
main→dev (en vez de push directo) y lo deja para merge manual, o lo auto-mergea si CI verde. Simple, respeta la protección; el back-merge deja de ser 100% automático salvo que se habilite auto-merge.
- Token con bypass: usar un PAT/GitHub App con permiso de bypass de branch protection para pushear a
dev. Mantiene la automaticidad pero agrega un secreto con privilegios.
- Permitir al bot en branch protection: agregar la identidad del workflow a la lista de bypass de
dev.
Recomendación tentativa: opción 1 (PR + auto-merge si CI verde) — sin secretos extra, respeta el flujo. Pero es decisión del PO (toca tokens/permisos).
Mientras tanto
El back-merge de 0.10.2 ya se hizo manual (PR #241). Cada release futuro necesita el PR manual hasta que se arregle esto.
Detectado en la sesión autónoma (al cerrar el flujo /release de 0.10.2).
Qué pasa
Tras cortar un release (ej. 0.10.2, #228), el step de back-merge automático en
release-please.ymlcorre e intenta pushearmain → devdirecto, perodevestá protegido → falla:Resultado: el back-merge no ocurre solo; hay que hacerlo a mano vía PR (lo hice en #241 para 0.10.2). La automatización queda en rojo en cada release.
Por qué importa
Sin back-merge,
devqueda atrás demainen el bump de versión + CHANGELOG → drift de versión/uv.lockque confunde al próximorelease-please. Hoy depende de que alguien recuerde hacer el PR manual. Encaja con el plan de "convertir fricciones en guardarraíles" (confianza para soltar/dormir).Opciones (decisión de infra/seguridad del PO)
main→dev(en vez de push directo) y lo deja para merge manual, o lo auto-mergea si CI verde. Simple, respeta la protección; el back-merge deja de ser 100% automático salvo que se habilite auto-merge.dev. Mantiene la automaticidad pero agrega un secreto con privilegios.dev.Recomendación tentativa: opción 1 (PR + auto-merge si CI verde) — sin secretos extra, respeta el flujo. Pero es decisión del PO (toca tokens/permisos).
Mientras tanto
El back-merge de 0.10.2 ya se hizo manual (PR #241). Cada release futuro necesita el PR manual hasta que se arregle esto.
Detectado en la sesión autónoma (al cerrar el flujo /release de 0.10.2).