GitHub

Esta guía cubre todo lo que pasa entre la plataforma y GitHub: qué permisos se piden, cómo llega un push a producción, qué commits esperan aprobación y qué hacer cuando el repositorio es de otra persona.

Tu cuenta

Se entra con GitHub, y la misma autorización deja a la plataforma listar tus repositorios: crear un servicio es elegir de una lista en vez de teclear owner/nombre.

Con una OAuth App se piden read:user, user:email y repo. repo es amplio (lectura y escritura sobre lo que tú alcanzas) y se pide porque listar repositorios privados es la función; si no lo concedes, entrar sigue funcionando y el nombre del repositorio se escribe a mano. El token se guarda cifrado y se retira en Settings → Applications de GitHub.

Quién ve tus repositorios. Tú ves los tuyos. Quien administra la instancia ve además, en el selector, los de quienes comparten un espacio con él, con el nombre y la cara de su dueño, para poder desplegarlos. Eso es una llamada de solo lectura a la lista; no se clona ni se lee código por esa vía.

Monorepos

Si el repositorio contiene varias aplicaciones, la plataforma las detecta leyendo su árbol y te deja elegir la carpeta antes del primer despliegue. Se cambia después en Ajustes → Origen o con fundaia settings tienda api --root apps/api.

Desplegar al hacer push

Desplegar solo con cada commit (en Ajustes → Origen, activado por defecto) hace que la plataforma siga la rama del servicio y despliegue cada commit nuevo. Mira la cabeza de la rama cada dos minutos; si la instancia tiene configurado el webhook de la GitHub App, se entera en segundos.

fundaia settings tienda api --auto-deploy false   # desplegar solo a mano
fundaia settings tienda api --branch develop      # seguir otra rama

Si la App también entrega el evento Pull request, un proyecto puede tener un entorno por cada pull request abierto, con su rama desplegada: ver Un entorno por pull request.

Con la GitHub App instalada, cada despliegue queda registrado junto al commit en GitHub, con un enlace a su página del commit.

Commits que esperan aprobación

Un commit se despliega solo si su autor, quien lo confirmó o quien fusionó su pull request es miembro del espacio (se compara por la cuenta de GitHub, no por el nombre). Los demás esperan: aparecen como primera fila del historial del servicio, con un reloj, hasta que un miembro los apruebe o los descarte. También esperan los commits cuyo correo no corresponde a ninguna cuenta de GitHub, casi siempre un git config user.email que su autor no añadió a su cuenta.

fundaia approvals tienda
fundaia approve <id>      # lo despliega
fundaia reject <id>       # no se vuelve a ofrecer

Un repositorio de otra persona

Si el repositorio es privado y de otra cuenta, la plataforma no puede leerlo hasta que su dueño lo permita. El despliegue falla en Descargando el código y GitHub lo explica mal: responde 403 Write access to repository not granted a una orden que solo pedía leer.

Solo el dueño puede concederlo, y la plataforma se lo pide:

fundaia access request tienda api --email dueño@ejemplo.com

fundaia access status tienda api dice en qué punto está: pending es que falta el correo y sent que se ha enviado. El enlace caduca en 21 días y se puede reenviar.

Un repositorio renombrado

Si el repositorio se renombra en GitHub, la plataforma lo sigue sola cuando la GitHub App recibe el aviso. Si no, cámbialo a mano en Ajustes → Origen o con:

fundaia settings tienda api --repo nuevo-owner/nuevo-nombre

Cambiar el repositorio o la rama no despliega: lo recoge el siguiente despliegue.

Desplegar con tags

Por defecto, un servicio de GitHub se despliega cada vez que se mueve su rama. Si prefieres publicar versiones a propósito, pon un patrón de tags en Ajustes → Origen → Desplegar con tags (fundaia settings <proyecto> <servicio> --deploy-tags "v*", o deployTagPattern en update_service_settings):

• Se despliega el tag más alto que encaje, comparado como versión: v1.10.0 va después de v1.9.0, y v2.0.0-rc.1 antes de v2.0.0. * vale cualquier cosa y ? un carácter (v*, release-*, v2.*).
• Los pushes a la rama dejan de desplegar; un tag nuevo, sí, en los dos minutos siguientes o al momento si la GitHub App tiene el webhook. Un tag que se mueve a otro commit con el mismo nombre se despliega de nuevo.
• El commit que se construye es el del tag, no la punta de la rama, y el historial lo marca con el nombre del tag. Volver a desplegar repite ese mismo tag.
• La aprobación de commits de fuera del espacio se aplica igual, sobre el commit del tag.
• Dejar el campo vacío vuelve a seguir la rama.