Saltar al contenido principal
Móvil Tutoriales CI/CD

Capgo Pull Request Preview Cleanup API Key

Aprende a utilizar una Capgo API clave para eliminar de manera segura las vistas previas de solicitudes de extracción, resetear vistas activas, eliminar paquetes y automatizar la limpieza de CI/CD.

Capgo Pull Request Preview Cleanup API Key

Elimina una vista previa de solicitud de extracción como un trabajo de un comando. Con CapgoSin embargo, hay un pequeño problema: debes alejarte de una vista activa antes de eliminarla, luego eliminar sus paquetes por ID. Construiremos un flujo de limpieza seguro con una clave restringida API, búsqueda de vistas, manejo de reset, eliminación de paquetes y automatización de CI.

Contenido del Artículo

  • Paso 1: Crea una Clave Restringida Capgo API para la Limpieza de Vista Previa
  • Paso 2: Identifica la Previsualización de Solicitud de Extracción y sus IDs de Conjunto
  • Paso 3: Cambia de la Vista Previa Activa antes de la Limpieza
  • Step 4: Elimina paquetes de vista previa por ID con la clave API
  • Step 5: Automatiza la limpieza cuando se cierra una solicitud de extracción
  • Step 6: Verifica la limpieza y protege los despliegues de la eliminación accidental
  • FAQ
  • Conclusion

Paso 1: Crea una clave Capgo API Restringida para la Previsualización de Limpieza

El primer paso en un flujo de limpieza de vista previa de solicitud de extracción Capgo es crear una clave que pueda realizar solo el trabajo que necesita su trabajo de CI.

No coloques una clave de organización amplia en un flujo de trabajo de solicitud de extracción. Una solicitud de extracción puede provenir de una rama que aún no ha ganado confianza. El flujo de trabajo también puede imprimir una instrucción o valor de entorno durante una ejecución fallida. Una clave estrecha limita el daño si eso sucede.

En Capgo, comienza con una clave de vista previa de aplicación para el trabajo de vista previa. La clave debe estar vinculada al ámbito de la aplicación o de la vista previa que gestiona su trabajo. Si su equipo utiliza el control de acceso basado en roles, limita la clave a aplicaciones seleccionadas en lugar de otorgar acceso a toda la organización. Capgo documenta esas opciones de clave de vista previa en su API key settings for web app workflows.

Almacena el secreto en el almacén de secretos cifrados de tu proveedor de CI. Dále un nombre que indique qué hace, comoCAPGO_PREVIEW_CLEANUP_KEYNo coloque en un archivo de flujo de trabajo, script de shell, comentario de solicitud de extracción o registro generado.

Transmita la clave al proceso de limpieza a través de una variable de entorno. Su script debe fallar cuando la variable esté ausente. Un fallback silencioso es peligroso porque puede convertir un trabajo de limpieza en una solicitud sin autenticación, o tentar a un desarrollador a pegar una clave en la línea de comandos.

if [ -z "$CAPGO_PREVIEW_CLEANUP_KEY" ]; then echo "Missing preview cleanup key" exit 1
fi

Considere mantener esta clave separada de la clave utilizada para publicar paquetes de producción. El trabajo de publicación puede necesitar subir una versión. El trabajo de limpieza solo necesita eliminar recursos de vista previa. Las claves separadas facilitan la revisión y reducen la posibilidad de que una acción de eliminación llegue a un canal de producción.

Utilice el mismo secreto en un entorno protegido cuando sea posible. Requiera aprobación antes de que un trabajo pueda tocar canales compartidos. Para vistas previas de solicitudes de extracción ordinarias, el trabajo debe funcionar en un canal temporal y nada más.

Tomar nota: Utilice una clave de vista de aplicación dedicada, limite su alcance de aplicación y manténgala en secretos de CI cifrados.

Antes de seguir adelante, pruebe la clave contra una acción de lectura inocua. Confirme que el trabajo puede ver la aplicación destinada, pero no puede acceder a una aplicación no relacionada o flujo de trabajo de producción. Los detalles exactos de la solicitud de limpieza no se publican completamente, así que mantenga su primer test pequeño e inspeccione la guía de soporte SDK o Capgo antes de agregar llamadas de eliminación.

Paso 2: Identifica el Previsualizador de Solicitud de Extracción y sus IDs de Conjunto

La clave de limpieza de vista previa de solicitud de extracción Capgo API es útil solo cuando su trabajo sabe qué vista previa y IDs de paquete son suyos.

Utilice una regla de nombramiento estable para los canales de vista previa. Un patrón común es el nombre del repositorio más el número de solicitud de extracción. El punto clave es la consistencia. Su tarea de limpieza debe reconstruir el mismo identificador después de que se cierra la solicitud de extracción.

Guarde el nombre del canal de vista previa cuando se crea la vista previa. Puede colocarlo en la salida del flujo de trabajo, una verificación de solicitud de extracción o un pequeño trozo de metadatos de trabajo. No se confíe en un nombre de visualización que una persona pueda cambiar en la consola.

En segundo lugar, liste los paquetes vinculados a esa vista previa. La acción de Eliminar paquete de Capgo requiere IDs de paquete. La documentación de origen apunta a una llamada de lista para recuperar todos los IDs de paquete disponibles antes de la eliminación. Trate esa lista como la fuente de verdad. Nunca adivine un ID a partir de un nombre de archivo, un hash de commit o un nombre de rama.

Filte los registros devueltos por el canal de vista previa o otro valor que controle su flujo de trabajo. Luego, mantenga el ID de paquete exacto para cada coincidencia. Si la lista está vacía, marque la limpieza como completa. Un resultado vacío no es un error a menos que su flujo de trabajo esperara una vista previa existente.

También registre el SHA del commit que produjo cada vista previa. Esto le da una segunda verificación antes de la eliminación. Si el nombre del canal coincide pero el commit no, deténgase y solicite una revisión. Ese pequeño retraso puede prevenir una carrera donde una nueva vista previa se está construyendo mientras una tarea de limpieza antigua se ejecuta.

Revisión de canal y ID de paquete de preview de solicitud de extracción para Capgo

No elimine mientras esté en ejecución un trabajo de publicación. Agregue una dependencia entre la compilación de vista previa y los flujos de trabajo de limpieza, o utilice un bloqueo claveado al número de solicitud de extracción. El trabajo de limpieza debe comenzar solo después del evento de cierre y después de que cualquier carga de vista previa pendiente haya terminado.

El Capgo público API cubre recursos como canales y paquetes a través de solicitudes HTTP autenticadas, pero las acciones de limpieza aún necesitan una verificación cuidadosa en tu proyecto. El Capgo público API de Capgo Es el lugar correcto para confirmar el modelo de recursos actual antes de escribir un wrapper.

Por ahora deberías tener un identificador de vista previa, una lista de IDs de paquetes exactos y el SHA de commit vinculado a cada registro. Si uno de esos valores falta, detente aquí. La limpieza sin verificaciones de propiedad es adivinanza.

Paso 3: Cambie a una vista previa inactiva antes de la limpieza

Una vista previa activa no puede eliminarse hasta que la aplicación cambie a ella o usted llameresetPreviewEsta es la clave en el flujo de limpieza de previsualización de solicitudes de extracción de Capgo.

Think of the active preview as the version currently selected by the app. Deleting the server-side record first would leave the app pointing at something that no longer exists. Capgo blocks that state change, so your cleanup job must reset the app’s preview state before it removes the preview.

Primero, comprueba si la vista previa sigue activa. Si lo está, mueve la aplicación a un canal seguro o utiliza la acción de reinicio del actualizador. La elección correcta depende de cómo esté configurada tu aplicación de prueba. Una aplicación de prueba desechable puede regresar a su canal de defecto normal. Una aplicación de prueba compartida puede necesitar un canal de etapa dedicado en su lugar.

UsaresetPreviewcuando se necesite borrar el estado de vista previa directamente. Mantén esta llamada vinculada a la misma solicitud de extracción y aplicación que crearon la vista previa. Un script de limpieza nunca debe reiniciar un dispositivo de producción o un canal de liberación compartido solo porque el nombre del canal coincida casualmente.

Hay una regla de ordenamiento útil aquí:

  • Confirm the pull request is closed.
  • No se está subiendo una vista previa.
  • Desplázate de la vista previa activa o llamaresetPreview.
  • Espera a que se complete ese cambio de estado.
  • Sólo entonces llama a Eliminar Vista Previa.

No trates una respuesta HTTP exitosa de la solicitud de reinicio como prueba de que la aplicación ya ha cambiado de estado en cada dispositivo. Un dispositivo puede verificar actualizaciones más tarde. Tu limpieza en servidor puede seguir adelante una vez que se haya eliminado la asignación de vista previa según la respuesta API, pero mantén el comportamiento del dispositivo separado de la eliminación de recursos.

Capgo admite el control de rollout basado en canales, lo que hace que esta separación sea más fácil de razonar. Un canal es un camino nombrado que le dice a una aplicación qué flujo de actualizaciones seguir. Tu canal de vista previa nunca debe ser el mismo canal utilizado por dispositivos de producción.

Para equipos que necesitan una frontera más estricta, utilice la documentación Capgo flujo de canal para automatización de vista previaDescribe la pauta de canal temporal y ayuda a mantener una tarea de limpieza alejada de los canales compartidos por defecto.

La documentación del actualizador de código abierto también registra el límite de eliminación: las vistas previas activas necesitan un cambio o un reinicio primero. Puede revisar el código en el repositorio del actualizador Capgo Capacitor. Ese código es útil cuando la palabra de la consola es demasiado breve para una decisión de CI.

Consejo: Haga que el reinicio sea un paso separado y registrado. Si falla la eliminación de la vista previa, el registro debe mostrar si la vista previa estaba activa o si el problema estaba en la solicitud de eliminación.

Una vez que el estado activo desaparece, el registro de la vista previa está listo para la eliminación. No combine el reinicio y la eliminación en una línea de comando opaca. Dos comandos claros son más fáciles de repetir y mucho más fáciles de auditar.

Paso 4: Eliminar paquetes de vista previa por ID con la API Clave

Eliminar cada paquete de vista previa por su ID exacto, después de que la vista previa activa se haya reiniciado. Es aquí donde una Capgo clave de limpieza elimina los objetos de almacenamiento dejados por la solicitud de extracción.

Comience con la lista de paquetes de vista previa del paso 2. Para cada ID que coincida, llame a la acción Eliminar Paquete a través de la Capgo SDK o el método público actual API disponible en su cuenta.

Inspeccione la firma del método SDK o confirme la forma actual de la solicitud con el apoyo de Capgo. Registre el método y el formato de respuesta en el libro de ejecución interno de su equipo una vez que los haya verificado. Ese libro de ejecución debe incluir la versión API, el identificador requerido y los códigos de error que su lógica de reintento puede manejar.

Use un modo de prueba seca en su script. Debe imprimir el canal de vista previa y los IDs de paquete que eliminaría, sin enviar solicitudes de eliminación. Ejecute ese modo contra varias solicitudes de extracción cerradas. Verifique que excluya los canales de producción y que no trate una lista vacía como un wildcard.

Un bucle de eliminación seguro tiene tres controles:

  1. Rechace un ID de paquete faltante o malformado.
  2. Rechazar un paquete cuyo canal no coincide con la vista previa de solicitud de extracción.
  3. Elimine solo después de que el control de propiedad pase.

Entonces maneje cada respuesta por tipo. Una eliminación exitosa puede registrarse como completa. Una respuesta no encontrada puede tratarse como ya limpia si el recurso se sabe que ha sido eliminado por un reintento anterior. Los errores de permiso deben fallar el trabajo y alertar al propietario. Los límites de velocidad deben pausar y reintentar con un retraso acotado.

No reintente cada error. Un ID malo no se volverá válido después de tres intentos. Un error de autorización suele significar que el alcance de la clave está mal. Reintente solo las fallas transitorias, y establezca un límite de tiempo máximo para que un trabajo de limpieza atascado no consuma su cola de CI.

La eliminación de paquetes está separada de la eliminación de previsualizaciones. La eliminación del canal de previsualización no elimina automáticamente todos los paquetes. Su trabajo debe retener un resultado para cada ID, luego hacer una solicitud de lista final si el API lo admite. Si cualquier paquete permanece, informe el ID y deténgase en lugar de afirmar silenciosamente éxito.

No incluya secretos en los registros de eliminación. Está bien registrar el número de solicitud de extracción, el nombre de la previsualización, el ID del paquete, el resultado de la solicitud y la fecha de tiempo. Nunca registre la clave API, una cabecera de autorización o un objeto de solicitud completo que podría incluir una.

Esta aproximación le da un registro útil de auditoría sin convertir el registro en otro lugar donde los credenciales pueden filtrarse. También hace que una eliminación fallida sea fácil de reanudar porque la próxima ejecución puede saltar registros ya confirmados como ausentes.

Paso 5: Automatizar la limpieza cuando se cierra una solicitud de extracción

Ejecuta el trabajo de limpieza desde el evento de cierre de solicitud de extracción, pero agrega comprobaciones que impidan que un nuevo build elimine una vista previa.

Su flujo de trabajo debe recibir el repositorio y el número de solicitud de extracción desde el payload del evento. Reconstruya el nombre del canal de previsualización a partir de esos valores. No acepte un nombre de canal proporcionado por un comentario de solicitud de extracción o una variable de rama no confiable.

Una secuencia de trabajo útil se parece a esto:

  1. Cargue la clave de eliminación restringida desde secretos cifrados.
  2. Confirme que el evento es una solicitud de extracción cerrada.
  3. Verifique que la previsualización pertenece al repositorio y la aplicación esperados.
  4. Espera a que cualquier despliegue de previsualización activo termine.
  5. Desplace la previsualización o llame aresetPreview.
  6. Liste los IDs de paquete para esa vista previa.
  7. Elimine cada paquete verificado.
  8. Elimine el registro de la vista previa.
  9. Escriba un resultado breve en la resumen del flujo de trabajo.

La orden importa. Si elimina primero, la regla de vista previa activa puede bloquear la solicitud. Si salta la llamada de lista, puede no saber cuáles son los IDs de paquete que aún existen. Si elimina por un nombre supuesto, corre el riesgo de tocar el recurso equivocado.

Automated CI/CD workflow for pull request preview cleanup

Utilice una regla de concurrencia claveada al número de solicitud de extracción. Cuando lleguen un evento de cierre y un evento de reconstrucción cerca de la misma hora, el trabajo de limpieza antiguo no debe correr con el nuevo despliegue. Cancelle un trabajo de limpieza obsoleto o haga que el trabajo espere hasta que el bloqueo de despliegue esté claro.

Capgo’s flujo de trabajo de una sola orden CLI puede reducir el número de llamadas de shell personalizadas alrededor de la construcción y el trabajo de liberación. Para nombres de comandos y operaciones admitidas, consulte la documentación del comando Capgo CLI. Utilice el CLI donde le dé un comando verificado. Utilice el SDK o el API público donde las acciones de limpieza necesitan una solicitud directa.

No ponga la limpieza en un flujo de trabajo que se ejecute con cada empuje. Un trabajo de empuje puede eliminar una vista previa que aún está siendo probada. El evento de cierre es el disparador correcto para la limpieza normal. Agregue un despliegue manual del flujo de trabajo para la recuperación cuando un trabajo falla.

Establezca un fallback de retención también. Si se pierde un evento de cierre, un trabajo programado puede encontrar vistas previas más antiguas que el plazo de prueba permitido por su equipo. Ese trabajo necesita medidas de seguridad más estrictas que la norma de cierre. Debe seleccionar solo vistas previas con un propietario claro y un timestamp vencido.

For GitHub Actions, keep permissions narrow and pass only the values needed by the cleanup step. Capgo’s current GitHub Actions integration documentation explains where the token is stored and how the workflow connects to Capgo.

Hasta ahora, debería tener un camino automatizado que reacciona a la cierre, espera a los trabajos en competencia, resetea el estado activo, lista IDs y elimina solo los conjuntos de paquetes coincidentes. Eso es rápido para el desarrollo diario sin hacer que la limpieza sea un cepillo de paja ciego.

Paso 6: Verifique la limpieza y proteja los lanzamientos de eliminación accidental

La verificación cierra el bucle de limpieza de previsualización de solicitud de extracción de Capgo. Una respuesta de eliminación sola no es suficiente para un proceso de liberación seguro.

La verificación cierra el bucle de limpieza de vistas previas de solicitudes de extracción de __CAPGO_KEEP_0__. Una respuesta de eliminación sola no es suficiente para un proceso de lanzamiento seguro.

Guarde estos valores en la resumen del trabajo:

  • Guarde estos valores en la resumen del trabajo:
  • Nombre de canal de previsualización.
  • Nombre del canal de vista previa.
  • IDs de paquete encontrados.
  • IDs de paquete eliminados.
  • Cualquier ID que devolvió un error.

Utilice un estado claro. "Limpio" significa que todos los objetivos verificados han desaparecido. "Ya está limpio" significa que el recurso estaba ausente antes de esta ejecución. "Necesita revisión" significa que uno o más controles fallaron. No etiquete una eliminación parcial como éxito.

Agregue una guardia de producción en code. Rechace nombres de canal como su canal predeterminado o de liberación. También rechace un paquete si su metadatos no coinciden con la aplicación de vista previa. La guardia debe fallar cerrada. Cuando el script no pueda identificar el objetivo con confianza, debe detenerse.

Mantenga la reversión separada de la limpieza. Una reversión cambia qué paquete los dispositivos reciben. La limpieza elimina un recurso de vista previa antiguo. Si un test encuentra un error después de que se cierra la solicitud de extracción, puede necesitar el paquete para la investigación. Establezca una ventana de retención corta en lugar de eliminar instantáneamente el evento si su equipo suele depurar después de la fusión.

Mire tres patrones de falla comunes:

  • Error de vista previa activa: Reinicia o cambia de ventana antes de volver a intentarlo.
  • ID de paquete faltante: ejecute la acción de lista nuevamente en lugar de adivinar.
  • Error de permiso: revisa el alcance de la clave, luego emita una nueva clave si es necesario.

Gire la clave de limpieza en un horario establecido por su política de seguridad, y gírela de inmediato si aparece en un registro o commit. Una nueva clave debe ser probada antes de que la antigua sea revocada, a menos que la exposición requiera una revocación inmediata.

La brecha documental alrededor de la limpieza merece una nota en su revisión de seguridad. Trate la guía SDK y verificada Capgo como la fuente para su implementación, y mantenga su propio contrato de solicitud bajo control de versión.

Toma en cuenta: Verificar la vista previa y la lista de paquetes después de la eliminación, bloquear objetivos de producción en code y reportar la limpieza parcial como un error.

Una sola orden es útil solo cuando los guardarropas están claros. Siga la vista previa. Adopte un nombre de canal predecible. Revierta los cambios de lanzamiento por separado. Luego, dé a la tarea de limpieza hacer su pequeño trabajo sin tocar el tráfico en vivo.

FAQ

Puedo eliminar una vista previa de solicitud de Capgo activa?

No. La vista previa activa debe cambiarse primero, o se debe llamar a resetPreviewDespués de que el estado activo se aclare, ejecute Eliminar Vista Previa. Esta regla es el detalle principal para recordar al configurar una clave de limpieza de vista previa de solicitud de Capgo API en CI.

¿Necesito IDs de paquete para limpiar una vista previa de Capgo?

Sí. La acción Eliminar Paquete de Capgo requiere los IDs de paquete, por lo que liste los paquetes disponibles antes de eliminarlos. Coincidir cada ID con el canal de vista previa y el commit antes de enviar una solicitud de eliminación. Nunca construya un ID a partir de un nombre de rama o asuma que eliminar la vista previa también elimina todos los paquetes.

¿Qué tipo de clave API debe usar CI para la limpieza de vista previa?

Utilice una clave de vista de aplicación restringida para la limpieza de vista, almacenada en el almacén de secretos cifrados de su proveedor de CI. Limitar la clave al aplicación o al alcance que necesita. Manténgala separada de la clave utilizada para publicar actualizaciones de producción. Esto hace que el trabajo de limpieza Capgo sea más fácil de revisar y más seguro de rotar.

Puedo automatizar la limpieza cuando se cierra una solicitud de extracción?

Sí. Desencadene la limpieza desde el evento de solicitud de extracción cerrada, luego espere a que se completen los trabajos de despliegue activos antes de resetear la vista previa. Enumere los IDs de paquete, elimine coincidencias verificadas y confirme el resultado. Agregue controles de concurrencia para que un edificio tardío no pueda correr el trabajo de limpieza.

¿Por qué mi solicitud de limpieza Capgo está fallando?

Las causas habituales son una vista previa activa, un ID de paquete faltante o una clave sin el alcance necesario. Resetee la vista previa primero, repita la llamada de lista y inspeccione las permisos de la clave. Dado que los detalles de la solicitud pueden variar según la versión API o SDK, confirme el método y los parámetros actuales antes de cambiar el script.

Conclusión

Use Capgo con una clave de vista previa dedicada y un orden de limpieza estricto: resetee la vista previa activa, enumere sus IDs de paquete, elimine paquetes verificados y luego elimine la vista previa. Comience con un ensayo seco contra una solicitud de extracción cerrada, confirme la forma de la solicitud en la versión actual SDK y agregue la guardia de canal de producción antes de activar la limpieza automática.

Actualizaciones en vivo para aplicaciones Capacitor

Cuando un bug de capa web está activo, envíe la corrección a través de Capgo en lugar de esperar días a la aprobación de la tienda de aplicaciones. Los usuarios obtienen la actualización en segundo plano mientras los cambios nativos siguen en el camino de revisión normal.

Últimas noticias de nuestro Blog

Capgo le da las mejores perspectivas que necesita para crear una aplicación móvil verdaderamente profesional.