Protección de ramas

Protección de ramas de Apothem en main: la regla de protección vigente, sus verificaciones de estado requeridas y las verificaciones pendientes de agregar.

La rama main de Apothem está protegida por una regla clásica de protección de rama de GitHub. El repositorio no tiene conjuntos de reglas. La protección hace cumplir la disciplina de conjunto de cambios declarada en rules/production-ready-prs.md y alimenta las comprobaciones Branch-Protection y Code-Review de OpenSSF Scorecard.

Esta página registra exactamente los ajustes vigentes, tal como se leyeron por última vez de la API de GitHub el 2026-10-07. Un ajuste que el mantenedor tiene previsto pero que todavía no ha aplicado aparece solo en Cambios pendientes del mantenedor.

Ajustes de protección

Ajuste	Campo de la API	Valor vigente	Efecto
Exigir una pull request antes de fusionar	`required_pull_request_reviews` (presente)	✅	Los cambios llegan a `main` a través de una pull request.
Revisiones de aprobación requeridas	`required_approving_review_count`	0	Una pull request se fusiona sin una revisión de aprobación. Consulta Modelo de mantenedor único.
Descartar aprobaciones obsoletas con nuevos commits	`dismiss_stale_reviews`	✅	Una aprobación otorgada antes de un nuevo push deja de contar.
Exigir la revisión de Code Owners	`require_code_owner_reviews`	❌	Habilitar esto antes de que se incorpore un segundo mantenedor produce un bloqueo mutuo en las pull requests de mantenedor único.
Exigir la aprobación del push revisable más reciente	`require_last_push_approval`	❌	GitHub exige que esa aprobación provenga de alguien distinto de quien hizo el push, algo que un mantenedor único no puede aportar.
Exigir que las verificaciones de estado pasen	`required_status_checks`	✅	Los 12 contextos listados en Verificaciones de estado requeridas deben pasar.
Exigir que las ramas estén actualizadas antes de fusionar	`required_status_checks.strict`	❌	Una pull request puede fusionarse cuando sus verificaciones requeridas pasaron contra un `main` más antiguo. Los flujos de trabajo que se ejecutan con un push a `main` prueban entonces el resultado fusionado.
Exigir la resolución de conversaciones antes de fusionar	`required_conversation_resolution`	✅	Los hilos de revisión abiertos bloquean la fusión.
Exigir commits firmados	`required_signatures`	❌	Los commits de lanzamiento se firman localmente. La aplicación obligatoria espera hasta que la documentación de incorporación de colaboradores describa la configuración de firma SSH o GPG.
Exigir historial lineal	`required_linear_history`	✅	Mantiene el historial público de `main` en una sola línea.
Bloquear la rama	`lock_branch`	❌	`main` acepta fusiones.
No permitir omitir los ajustes anteriores	`enforce_admins`	❌	Los ajustes anteriores no obligan a un administrador del repositorio. Un administrador puede fusionar sin las verificaciones requeridas o hacer push directamente a `main`.
Permitir force pushes	`allow_force_pushes`	❌	Los force pushes a `main` están bloqueados para todos, incluidos los administradores.
Permitir eliminaciones	`allow_deletions`	❌	Nadie puede eliminar `main`, incluidos los administradores.

Modelo de mantenedor único

El repositorio tiene un solo mantenedor. GitHub indica: «Los autores de una pull request no pueden aprobar sus propias pull requests». Por lo tanto, un número de aprobaciones requeridas superior a 0 bloquearía todas las pull requests del mantenedor. La regla vigente exige una pull request con 0 aprobaciones y deja enforce_admins desactivado.

Para cualquier persona sin permiso de administrador, una fusión sigue necesitando las verificaciones de estado requeridas en verde, las conversaciones de revisión resueltas y un historial lineal. Los force pushes y la eliminación de main siguen bloqueados para todas las cuentas.

Cuando se incorpore un segundo mantenedor, los ajustes más estrictos son al menos una aprobación requerida, la aprobación del último push, la revisión de CODEOWNERS y enforce_admins activado. La ceremonia de fusión para mantenedor único se aplica solo a una protección que exige una aprobación y la aplica a los administradores.

Verificaciones de estado requeridas

Cada uno de estos 12 contextos es obligatorio, con GitHub Actions (ID de app 15368) como origen:

quality / ubuntu-latest / py3.10
quality / ubuntu-latest / py3.11
quality / ubuntu-latest / py3.12
quality / ubuntu-latest / py3.13
quality / ubuntu-latest / py3.14
quality / windows-latest / py3.10
quality / windows-latest / py3.11
quality / windows-latest / py3.12
quality / windows-latest / py3.13
quality / windows-latest / py3.14
coverage
Require Signed-off-by

Contexto	Flujo de trabajo y trabajo	Cómo informa en cada pull request
`quality / <os> / py<ver>` (10)	`ci.yml`, trabajo `quality`	`ci.yml` se ejecuta cuando una pull request modifica una ruta de código o de configuración. `ci-docs-stub.yml` informa los mismos contextos en una pull request solo de documentación.
`coverage`	`ci.yml`, trabajo `coverage`	Igual que `quality`.
`Require Signed-off-by`	`dco.yml`, trabajo `dco`	Su disparador de pull request no tiene filtro `paths`, por lo que se ejecuta en cada pull request a `main`.

La celda de prelanzamiento quality / ubuntu-latest / py3.15 se ejecuta en ci.yml con continue-on-error y no es obligatoria. Cualquier otro flujo de trabajo, incluidos CodeQL, Scorecard y pip-audit, puede informar un estado, pero su resultado no condiciona la fusión a menos que su contexto se agregue a esta lista.

Cambios pendientes del mantenedor

El mantenedor tiene previsto agregar estos 25 contextos a la lista de obligatorios. El encabezado de cada flujo de trabajo declara el trabajo como verificación requerida, y su disparador de pull request no tiene filtro paths, por lo que se ejecuta en cada pull request a main. Hasta que se agregue un contexto, un fallo en él no bloquea la fusión.

clean-install-gate.yml, 7 contextos:

installer-shell-compat / ubuntu-latest
installer-shell-compat / macos-latest
installer-shell-compat / windows-latest
clean-install-gate / ubuntu-latest
clean-install-gate / windows-latest
wheel-smoke / ubuntu-latest
wheel-smoke / windows-latest

harness-matrix.yml, 17 contextos, un matrix (<adapter>) por cada adaptador de la matriz del trabajo:

matrix (antigravity)
matrix (claude-code)
matrix (codebuddy)
matrix (codex)
matrix (cursor)
matrix (gemini-cli)
matrix (github-copilot)
matrix (glm)
matrix (hermes)
matrix (kimi-code)
matrix (kiro)
matrix (open-claw)
matrix (opencode)
matrix (qwen-code)
matrix (trae)
matrix (windsurf)
matrix (zed)

installer-lint.yml, 1 contexto:

installer-lint

Una vez que los contextos de harness-matrix.yml sean obligatorios, registrar un nuevo adaptador agrega un contexto matrix (<adapter>), y la lista de obligatorios lo incorpora en el mismo cambio. «Exigir que las ramas estén actualizadas antes de fusionar» sigue desactivado. Cuando se aplique un cambio pendiente, muévelo a las secciones de la configuración vigente de arriba en el mismo cambio.

Cadencia de auditoría

Este archivo se revisa en cada auditoría de seguridad y en cada punto de control de ingeniería de lanzamientos. Una desviación entre este archivo y la configuración real de protección de rama es un hallazgo de severidad alta. Lee la configuración vigente con:

gh api repos/ahmed-g-gad/apothem/branches/main/protection
gh api repos/ahmed-g-gad/apothem/rulesets

Referencias

OpenSSF Scorecard — comprobación Branch-Protection
GitHub — Acerca de las ramas protegidas
GitHub — Administrar una regla de protección de rama
GitHub — Aprobar una pull request con revisiones requeridas
CODEOWNERS de Apothem — propiedad de revisión con alcance por ruta
Flujos de trabajo de CI de Apothem — los flujos de trabajo de los que proviene cada contexto requerido
rules/production-ready-prs.md §1 — la disciplina de mismo conjunto de cambios que esta protección hace cumplir

Protección de ramas

Ajustes de protecciónCopy Anchor Link

Modelo de mantenedor únicoCopy Anchor Link

Verificaciones de estado requeridasCopy Anchor Link

Cambios pendientes del mantenedorCopy Anchor Link

Cadencia de auditoríaCopy Anchor Link