Conectar un repositorio de Azure DevOps

Orbit realiza implementaciones desde Azure Repos, el alojamiento de git dentro de Azure DevOps. Conéctate una vez, elige un repositorio y cada push se compila e implementa en vivo. Esta guía cubre ambas formas de conectarse, seleccionar un repositorio y las dos cosas que Azure hace de forma diferente a los otros proveedores.

Dos Formas De Conectarse, Y Por Qué Hay Dos

Las organizaciones de Azure DevOps pueden bloquear aplicaciones de terceros a nivel de inquilino, y muchas empresas lo hacen. Si la tuya lo hace, el botón de inicio de sesión no puede funcionar para ti sin importar lo que hagamos, así que Orbit ofrece una segunda puerta que siempre funciona.

• Iniciar sesión con Microsoft. Un clic, nada que copiar y pegar. Disponible cuando tu organización permite aplicaciones de terceros.
• Token de acceso personal. Funciona para todas las organizaciones, incluyendo las que bloquean aplicaciones. Pegas un nombre de organización y un token que creas en Azure DevOps.

Ambas puertas llegan exactamente a las mismas funciones. Ninguna es una versión reducida de la otra.

Antes De Empezar

Opción A: Iniciar Sesión Con Microsoft

1. En KPanel, haz clic en Orbit en la barra lateral izquierda.
2. Haz clic en Nuevo proyecto.
3. Deja el modo configurado en Importar repositorio de Git.
4. Elige la pestaña Azure DevOps y luego haz clic en Conectar Azure DevOps.

Se te enviará a Microsoft para que inicies sesión y apruebes el acceso. Apruébalo y serás devuelto a KPanel con tus repositorios cargados.

Si tu organización bloquea la aplicación, Microsoft se niega y KPanel muestra la razón que dio. Eso no es algo que puedas resolver reintentando: usa el token de acceso personal a continuación, o pídele a un administrador que permita la aplicación.

Opción B: Token De Acceso Personal

Crea el token en Azure DevOps primero.

1. En Azure DevOps, abre Configuración de usuario, luego Tokens de acceso personal, luego Nuevo token.
2. Elige la organización desde la que deseas implementar.
3. Otorga estos tres alcances y no más que estos tres:
   • Código (Lectura) para que Orbit pueda listar tus repositorios y descargar el commit que está compilando.
   • Código (Estado) para que el resultado de la compilación aparezca en el commit y en la solicitud de extracción.
   • Enlaces de servicio (Lectura y escritura) para que Orbit pueda suscribirse a tus pushes.
4. Copia el token. Azure lo muestra una sola vez.

Luego en KPanel:

1. Abre Orbit, luego Nuevo proyecto, luego la pestaña Azure DevOps.
2. En Conectar con un token de acceso personal, ingresa el nombre de tu organización. Esa es la parte de la dirección de tu repositorio inmediatamente después de dev.azure.com, así que para https://dev.azure.com/contoso/web-platform/_git/storefront la organización es contoso.
3. Pega el token y haz clic en Conectar Azure DevOps.

Orbit usa el token inmediatamente para listar tus repositorios. Si se rechaza, se te dice qué alcances faltan en lugar de pedirte que verifiques tu token, porque un token que lista repositorios pero no puede crear un enlace de servicio es la forma que se conecta limpiamente y luego nunca implementa nada.

Tu token se cifra antes de almacenarse y solo se usa contra la organización que nombraste.

Seleccionar Un Repositorio

Tus repositorios aparecen como una lista, nombrada organisation / project / repository. Los repositorios de Azure tienen tres partes, no dos, porque dos proyectos en una organización pueden contener cada uno un repositorio con el mismo nombre.

Haz clic en Seleccionar al lado del que deseas, luego termina el proyecto como de costumbre: nombre, marco de trabajo, configuración de compilación, variables de entorno.

Si Falta Un Repositorio

• Verifica la organización. Un token de acceso personal pertenece a UNA organización, así que un repositorio en una diferente no aparecerá. Conecta esa organización también.
• Verifica tu acceso en el repositorio mismo en Azure DevOps.
• Verifica si el repositorio está deshabilitado en Azure. Orbit no lista repositorios deshabilitados, porque no pueden compilarse.

Dos Cosas Que Azure Hace Diferente

Estas son diferencias reales, no brechas a las que aún no llegamos, y ambas se indican aquí en lugar de descubrirse más tarde.

El Directorio Raíz De Monorepo No Omite Pushes

En los otros proveedores, Orbit lee la lista de archivos que cada push cambió, y un proyecto de monorepo puede omitir una compilación cuando nada bajo su Directorio Raíz se movió. Azure no envía esa lista. Orbit, por lo tanto, compila en cada push en lugar de adivinar, porque adivinar de la otra manera omitiría silenciosamente implementaciones que esperabas.

Tu configuración de Directorio Raíz aún decide dónde se ejecuta la compilación. Solo que no filtra además qué pushes compilan.

Las Solicitudes De Extracción Desde Forks No Se Compilan

Orbit compila una vista previa de solicitud de extracción con las variables de entorno de Vista Previa de tu proyecto. Eso es seguro para una solicitud de extracción desde tu propio repositorio y no es seguro para una desde un fork, que es una propuesta de alguien sin relación con tu cuenta.

En GitHub, Orbit puede ofrecer una vista previa de fork porque GitHub publica el commit propuesto dentro de tu propio repositorio, así que nunca tenemos que autenticarnos contra la copia del colaborador. Azure no publica un equivalente, así que Orbit rechaza solicitudes de extracción de forks y lo dice en el commit en lugar de dejar una vista previa que nunca aparece.

Las solicitudes de extracción de ramas dentro de tu propio repositorio se compilan normalmente.

Qué Sucede A Continuación

Realiza un push a tu rama de producción y Orbit compila e implementa. El resultado de la compilación se publica nuevamente en el commit en Azure DevOps, así que aparece en el commit y en cualquier solicitud de extracción a la que pertenezca el commit, y tus políticas de rama pueden requerirlo.

Ver También

• ¿Qué es Orbit?
• Implementar Con Orbit
• Conectar un Repositorio de GitHub