Laravel Cloud CLI ya entiende repositorios de GitLab y Bitbucket
cloud-cli 0.6.0 detecta más proveedores Git y evita esperas indefinidas durante el flujo de despliegue.
El remoto ya no tiene que ser GitHub
Si el código de un proyecto vive en GitLab o Bitbucket, que el CLI de despliegue dé por hecho GitHub acaba generando fricción donde no debería haberla. No es solo una etiqueta incorrecta: el proveedor forma parte de cómo Laravel Cloud identifica el repositorio y de los enlaces que muestra hacia ramas o commits. La versión 0.6.0 de cloud-cli incorpora soporte para GitLab y Bitbucket junto al proveedor de GitHub existente. (github.com)
La vía normal es sencilla: el CLI toma el proveedor a partir del remoto origin. Esto permite mantener el flujo habitual cuando el repositorio está bien configurado y evita añadir datos duplicados a mano. Para los casos en los que el host no se pueda reconocer, el comando puede pedir el proveedor de forma interactiva o recibirlo con --source-provider. (github.com)
Elegir el proveedor cuando hace falta
La opción está disponible en cloud ship y también al crear o actualizar aplicaciones. Los valores admitidos en esta versión son github, gitlab, gitlab_self_hosted y bitbucket. En una automatización prefiero declararlo de forma explícita si el remoto no es el estándar o si el repositorio se prepara en un paso anterior del pipeline. (github.com)
cloud application:create \
--repository=equipo/mi-aplicacion \
--source-provider=gitlab \
--region=us-east-2 \
-nEl ejemplo usa opciones documentadas por el propio CLI: repositorio, proveedor, región y modo no interactivo. En un repositorio convencional, sin embargo, no hace falta forzar --source-provider si origin apunta a un host reconocido. La mejora importante está en que el proveedor deja de ser una suposición implícita y pasa a viajar con los datos de la aplicación. (github.com)
Un cloud ship que no se queda esperando para siempre
El otro cambio relevante está en la comprobación final de disponibilidad dentro de cloud ship. En la versión 0.6.0 esa espera tiene un límite de 120 segundos y también contempla fallos de conexión mientras el dominio todavía no resuelve. Si el plazo termina sin una respuesta válida, el comando no se queda bloqueado indefinidamente. (github.com)
Esto importa especialmente en CI, donde un proceso colgado consume minutos, bloquea ejecutores y deja un resultado ambiguo. Ahora el flujo puede terminar con un aviso y dejarte decidir si revisas los logs o si haces que el pipeline trate el resultado como un fallo. No convierte el despliegue en correcto por sí solo, pero sí hace que el comportamiento sea acotado y manejable. (github.com)
La letra pequeña
Conviene no interpretar esta novedad como integración completa con todos los proveedores. Para Bitbucket, el propio proyecto indica que no existe una ruta de creación de repositorio desde el CLI: hay que crear el repositorio fuera y añadirlo como remoto antes de continuar. GitLab y Bitbucket quedan cubiertos para detección, envío del proveedor y construcción de enlaces, pero eso no sustituye la configuración de accesos que necesite cada repositorio. (github.com)
También hay un detalle útil sobre la espera de disponibilidad. Un 404 se interpreta como que el dominio todavía no está encaminando hacia la aplicación y se sigue reintentando; en cambio, un 401 o un 403 se consideran una respuesta válida de una aplicación que puede proteger su ruta raíz. Los errores de servidor no se dan por buenos, y un error de conexión se reintenta hasta agotar el tiempo. (github.com)
Por eso no usaría esta comprobación como monitorización de salud completa. Que la URL principal responda no garantiza que las colas, los workers, una ruta autenticada concreta o una dependencia externa estén funcionando. Para validar un despliegue en producción, sigue teniendo sentido combinar el CLI con pruebas HTTP propias, logs y alertas fuera del proceso de publicación.
Para quién tiene sentido actualizar
Si todos tus proyectos están en GitHub y ejecutas cloud ship de forma manual, el cambio será poco visible. Si mantienes proyectos Laravel en GitLab, Bitbucket o una instancia propia de GitLab, elimina una incompatibilidad real del flujo. Y si despliegas desde automatizaciones, tener una espera con salida definida es una mejora práctica aunque no cambie ni una línea de tu aplicación. (github.com)
Fuente original · Documentación oficial de Laravel Cloud CLI