Motivación e Introducción  Las vistas previas de compilación no son nada nuevo o innovador. Heroku los tuvo durante años. Sin embargo, si está construyendo en Google Cloud Platform, las cosas son un poco más difíciles. Google Cloud Build se puede usar para implementar en Cloud Functions, Cloud Run, Kubernetes, App Engine, etc., etc. Esto es lo que complica un poco las vistas previas, ya que Cloud Build no sabe dónde está implementando su aplicación o servicio. Tienen una aplicación GitHub para conectar los repositorios y mostrar el estado de compilación en GitHub, pero eso es todo. Sin vistas previas, comentarios ni ninguna de las cosas "normales" a las que estamos acostumbrados con productos como Heroku, Vercel o Fly.  Hay una forma "fácil" de publicar un comentario en una solicitud de extracción de GitHub desde Cloud Build con una simple solicitud HTTP. Pero, ¿por qué es fácil cuando puede usar la   ? API de implementaciones de GitHub  Con esta API, puede crear entornos, tener diferentes variables por entorno y mostrar el estado de compilación e implementación directamente en una solicitud de incorporación de cambios. Y una vez que se realiza la implementación en su plataforma de CD, puede agregar la URL al estado de implementación. Esto es lo que vamos a hacer en este artículo.   Estado de implementación de GitHub  Nuevamente, hay otra forma de hacer esto mediante el uso de la API de implementaciones directamente con solicitudes HTTP. Sin embargo, esto puede ser complicado a veces y deberá definir un token de acceso personal para autenticarse con GitHub. En cambio, decidimos armar un pequeño servicio de Node.js que usa GitHub Apps para generar un token de aplicación e interactuar con la API de implementaciones. Esto permite un control un poco más preciso sobre el proceso de implementación.  Descargo de responsabilidad  Este artículo está escrito exclusivamente para Google Cloud Platform y GitHub. Se asume una comprensión básica de Google Cloud Platform, Google Cloud Build y los permisos de IAM.  Debe tener un proyecto de Google Cloud Platform configurado.  Implementador de GitHub (Node.js y Docker)  GitHub Deployer es un pequeño servicio de Node.js que se autoriza con una aplicación de GitHub e interactúa con la API de implementaciones de GitHub. Los comandos están predefinidos y es necesario integrar cierta información en la imagen de Docker, ya que, de lo contrario, la configuración del tiempo de ejecución en Cloud Build sería demasiado compleja.  La imagen de Docker no está lista; deberá compilarlo usted mismo y enviarlo a su registro. El mejor lugar es Google Artifact Registry, donde también se almacenan las imágenes de su aplicación (Container Registry está obsoleto):  Si aún no lo ha hecho, cree un repositorio de registro de artefactos  Cree una aplicación de GitHub e instálela en su organización   Crear una aplicación de GitHub  Permisos requeridos: 'pull_requests', 'implementaciones', 'metadatos'  Copie la ID de la aplicación (desde la pantalla de configuración de la aplicación) y la ID de instalación de la aplicación (después de hacer clic en "Configurar", encontrará la ID de instalación en la URL. No tengo idea de dónde más se puede encontrar)  Cree y descargue una clave privada y conviértala a base64 (   )  base64 -i your.private-key.pem  Cree la imagen de Docker   Fuente  Cloud Build se ejecuta en   , por lo que necesitamos   para crear la imagen para la plataforma x86: amd64 buildx   docker buildx build --platform linux/amd64 . -t us-central1-docker.pkg.dev/[PROJECT]/docker/gh-deployer \   --build-arg GH_APP_ID=[GITHUB_APP_ID] \   --build-arg GH_APP_PRIVATE_KEY=[GITHUB_PRIVATE_KEY_BASE_64] \   --build-arg GH_APP_INSTALLATION_ID=[GITHUB_INSTALLATION_ID] \   --build-arg GH_OWNER=[GITHUB_ORG]  Empuje la imagen a su registro:   docker push us-central1-docker.pkg.dev/[PROJECT]/docker/gh-deployer  Ejecute la imagen de Docker localmente   docker run -it -e REPO_NAME=test -e REF=main -e ENVIRONMENT=test us-central1-docker.pkg.dev/[PROJECT]/docker/gh-deployer:latest create  Variables de entorno requeridas:    :   el nombre del repositorio (por ejemplo,   ) REPO_NAME requiere gh-deployer    :   la rama, etiqueta o SHA para implementar (por ejemplo,   ) REF requiere main    :   el entorno para implementar (por ejemplo,   ) ENVIRONMENT requiere preview    :   si se establece en   , la implementación se eliminará después de cierto tiempo TRANSIENT_ENVIRONMENT opcional/falso true    :   una descripción de la implementación DESCRIPTION opcional  Los siguientes comandos están disponibles como primer argumento:    - crear una nueva implementación create    : la compilación está pendiente pending    - la compilación está en progreso in_progress    : la compilación está en cola queued    - la implementación fue exitosa success    - algo salió mal error    : la implementación falló failure  Con Cloud Build, las opciones actualmente son un poco limitadas. No hay un estado   , ya que Cloud Build debe iniciarse para crear la implementación inicial.   tampoco tiene mucho sentido, por lo que en nuestra propia configuración, estamos usando lo siguiente: pending queued    para crear la implementación transitoria para una confirmación gh-deployer/create    directamente después de crear pgh-deployer/ending  Ejecute kaniko build para crear la imagen de Docker para su implementación.    después de completar la compilación y antes de implementar la imagen gh-deployer/in_progress    después de implementar la imagen gh-deployer/success  Nuevamente, con Cloud Build no sabemos dónde se realizará la implementación, por lo que hay dos formas de pasar la URL de implementación al paso   : success  En un paso de compilación, escriba la URL en  /workspace/deployer_environment_url  Pase un segundo argumento a la imagen de Docker después  success  Usamos Cloud Run para nuestras implementaciones, así que este es el paso de compilación para recuperar la URL de implementación para un número de solicitud de extracción determinado:  - nombre: gcr.io/google.com/cloudsdktool/cloud-sdk   env: - PR_NUMBER=$_PR_NUMBER script: >- gcloud run services list --project [project] --filter preview-$PR_NUMBER --format "value(status.address.url)" > /workspace/deployer_environment_url  Configuración de compilación en la nube/Terraform  cloudbuild.yaml   cloudbuild.yaml  Aquí hay un ejemplo completo usando el archivo de configuración   . Usamos Kaniko para construir y Cloud Run como objetivo de implementación. cloudbuild.yaml  Si trabaja con Terraform, también hay un archivo de Terraform que falla:  preview.tf  Acciones de GitHub  Al utilizar la API de implementaciones, puede desencadenar acciones de GitHub en   . Esto facilita la ejecución de comprobaciones de control de calidad, pruebas de extremo a extremo, etc. en cada compilación de vista previa. Aquí hay un ejemplo para ejecutar   en cada vista previa usando la   que se pasa para el estado   : deployment_status Playwright environment_url success  dramaturgo-qa:   if: ${{ github.event.deployment\_status.state == 'success' }} timeout-minutes: 60 runs-on: ubuntu\-latest steps: \- uses: actions/[\[email protected\]](/cdn-cgi/l/email-protection) \- uses: actions/setup\-[\[email protected\]](/cdn-cgi/l/email-protection) with: node-version: 20 cache: 'npm' \- run: npm ci \- name: Install Playwright Browsers run: npm exec playwright install \-\-with\-deps \-y \- name: Run Playwright tests run: pnpm exec playwright test env: BASE\_URL: ${{github.event.deployment\_status.environment\_url}} \- uses: actions/upload\-[\[email protected\]](/cdn-cgi/l/email-protection) if: always() with: name: playwright\-report path: playwright\-report/ retention-days: 30  Optimizaciones  la imagen básica   es relativamente grande. Puede   para acelerar las compilaciones. gcr.io/google.com/cloudsdktool/cloud-sdk crear su propia imagen pequeña de gcloud con componentes de Cloud Run  Conclusión   Estado de implementación de GitHub Listo  Los comentarios sobre las solicitudes de extracción de GitHub son fáciles al principio, pero cuando tiene múltiples implementaciones por solicitud de extracción, compilaciones fallidas, etc., no ofrecen mucha flexibilidad y son difíciles de mantener/actualizar. La API de implementaciones de GitHub ofrece una forma elegante de crear y administrar implementaciones desde cualquier sistema CI/CD de terceros. Con   intentamos agilizar la interacción con la API de implementaciones y solucionar algunos efectos secundarios o dificultades que son imposibles de resolver solo con la API HTTP. GitHub Deployer  Otro beneficio de usar la API de implementaciones de GitHub es que puede usar el disparador   para las acciones de GitHub y obtener la   directamente con la carga útil del evento. deployment_status environment_url  Puede encontrar instrucciones de instalación / compilación un poco más detalladas y todo el código en el  repositorio de GitHub    ,   /   o   . Si tiene alguna pregunta o comentario comuníquese con BlueSky Twitter únase a la discusión en GitHub  También publicado  aquí.

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Read My Stories

Problem Solver at Zentered

Este audio es producido en el idioma original de la historia!

Implementaciones de GitHub (versión preliminar) con Google Cloud Platform: una guía esencial

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Una breve introducción a la teoría del cerebro de Boltzmann

Telegram: el puente de Crypto Island hacia el continente

Una guía del arquitecto para crear una arquitectura de referencia para un lago de datos de IA/ML

Navegando por las aguas: desarrollo de aplicaciones RAG de nivel de producción con lagos de datos

Una breve introducción a la teoría del cerebro de Boltzmann

Telegram: el puente de Crypto Island hacia el continente

Una guía del arquitecto para crear una arquitectura de referencia para un lago de datos de IA/ML

Navegando por las aguas: desarrollo de aplicaciones RAG de nivel de producción con lagos de datos

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps