Capgo Pull Request Preview Cleanup API Key

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

Índice de Contenido

• Paso 1: Crea una Clave de Capgo API Restringida para la Limpieza de Previsualizaciones
• Paso 2: Identifica la Previsualización de Solicitud de Extracción y sus IDs de Paquetes
• Paso 3: Cambia de la Previsualización Activa antes de la Limpieza
• Paso 4: Elimina los Paquetes de Previsualización por ID con la Clave de API
• Paso 5: Automatiza la Limpieza cuando una Solicitud de Extracción se Cierre
• Paso 6: Verifica la Limpieza y Protege los Despliegues de Eliminación Accidental
• FAQ
• Conclusión

Paso 1: Crea una clave restringida Capgo API para la limpieza de previsualización

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

No coloque 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, comience con una clave de previsualización de aplicación para el trabajo de previsualización. La clave debe estar vinculada al ámbito de aplicación o de previsualización que su trabajo gestiona. Si su equipo utiliza control de acceso basado en roles, limite la clave a aplicaciones seleccionadas en lugar de otorgar acceso a toda la organización. Capgo documenta esas opciones de clave de previsualización en su API key settings for web app workflows.

Almacene el secreto en el almacén de secretos cifrados de su proveedor de CI. Le dé un nombre que diga 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.

Proporcione 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 la aprobación antes de que un trabajo pueda tocar canales compartidos. Para las 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 deseada, 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 previsualización de solicitud de extracción Capgo es útil solo cuando su trabajo conoce los IDs de previsualización y de paquete que posee API.

Utilice una regla de nombramiento estable para 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 trabajo de limpieza debe reconstruir el mismo identificador después de que se cierre la solicitud de extracción.

Guarda el nombre del canal de vista previa cuando se crea la vista previa. Puedes 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 confíes en un nombre de visualización que una persona pueda cambiar en la consola.

En segundo lugar, enumera 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. Trata esa lista como la fuente de verdad. Nunca supongas un ID a partir de un nombre de archivo, un hash de commit o un nombre de rama.

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

También registra el SHA de commit que produjo cada vista previa. Esto te da una segunda verificación antes de la eliminación. Si el nombre del canal coincide pero el commit no, detente y solicita una revisión. Ese pequeño retraso puede prevenir una carrera donde una nueva vista previa se está construyendo mientras un trabajo de limpieza antiguo se ejecuta.

No elimines mientras un trabajo de publicación esté aún en ejecución. Agrega una dependencia entre la construcción de la vista previa y los flujos de trabajo de limpieza, o utiliza 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 pendiente de subida de vista previa haya terminado.

Capgo’s public API cubre recursos como canales y paquetes a través de solicitudes HTTP autenticadas, pero las acciones de limpieza todavía necesitan una verificación cuidadosa en tu proyecto. El Capgo public API resumen es el lugar adecuado para confirmar el modelo de recursos actual antes de escribir un wrapper.

Ahora deberías tener un identificador de previsualización, una lista de IDs de paquetes exactos y el SHA del commit asociado a cada registro. Si uno de esos valores falta, detente aquí. La limpieza sin comprobaciones de propiedad es adivinanza.

Paso 3: Cambiar a una previsualización inactiva antes de la limpieza

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

Piensa en la previsualización activa como la versión seleccionada actualmente por la aplicación. Eliminar el registro del lado del servidor primero dejaría la aplicación apuntando a algo que ya no existe. Capgo bloquea ese cambio de estado, por lo que tu trabajo de limpieza debe restablecer el estado de previsualización de la aplicación antes de eliminar la previsualización.

Primero, verifica si la previsualización 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 eliminar el estado de previsualización directamente. Mantenga esta llamada vinculada al mismo pull request y aplicación que crearon la previsualización. Un script de limpieza nunca debe resetear 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í:

• Confirme que el pull request está cerrado.
• No se está subiendo una vista previa.
• Cambie de la previsualización activa o realice la llamadaresetPreview.
• Espera a que se complete el cambio de estado.
• Llame a Delete Preview solo entonces.

No trate una respuesta HTTP exitosa de la solicitud de reseteo como prueba de que la aplicación ya ha cambiado de estado en todos los dispositivos. Un dispositivo puede verificar actualizaciones más tarde. Su limpieza en servidor puede seguir una vez que la asignación de previsualización se haya eliminado según la respuesta API, pero mantenga 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. Su canal de previsualización 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 para la automatización de la limpieza de previsualizaciónDescribe el patrón de canal temporal y ayuda a mantener un trabajo de limpieza alejado de los canales de defecto compartidos.

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

Consejo: Haga que el reinicio sea un paso separado registrado. Si falla la eliminación de la vista previa, el registro debe mostrar si la vista previa estaba aún activa o si el pedido de eliminación tenía otro problema.

Una vez que el estado activo ha desaparecido, 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 shell 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 clave API

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

Comience con la lista de paquetes de Step 2. Para cada ID coincidente, 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 de solicitud actual con el soporte 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 repetición puede manejar.

Use un modo de prueba seco en tu script. Debe imprimir el canal de vista previa y los IDs de paquete que eliminaría, sin enviar solicitudes de eliminación. Ejecuta ese modo contra varias solicitudes de extracción cerradas. Verifica 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 puertas:

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 pase la verificación de propiedad.

Luego 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 una repetición anterior. Los errores de permiso deben fallar el trabajo y alertar al propietario. Los límites de velocidad deben pausar y repetir con un retraso acotado.

No repita 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. Repita solo las fallas transitorias, y establezca un límite de tiempo de ejecución para que un trabajo de limpieza atascado no consuma tu cola de CI.

La eliminación de paquetes es separada de la eliminación de vistas previas. Eliminar el canal de vista previa no prueba automáticamente que todos los paquetes han ido. Tu trabajo debe retener un resultado para cada ID, luego realice una solicitud de lista final si el API lo permite. Si cualquier paquete permanece, informe el ID y deténgase en lugar de afirmar silenciosamente el éxito.

Considere eliminar los registros de eliminación libres de secretos. Es aceptable registrar el número de solicitud de extracción, el nombre de la vista previa, el ID de paquete, el resultado de la solicitud y la fecha y hora. Nunca registre la clave API, un encabezado de autorización o un objeto de solicitud completo que podría incluir uno.

Esta aproximación te da un útil registro de auditoría sin convertir el registro en otro lugar donde los credenciales pueden filtrarse. También hace que una limpieza 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.

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

Una secuencia útil de trabajo se parece a esto:

1. Carga la clave de limpieza restringida desde secretos cifrados.
2. Confirma que el evento es una solicitud de extracción cerrada.
3. Verifica que la vista previa pertenece al repositorio y la aplicación esperados.
4. Espera a que cualquier despliegue activo de vista previa termine.
5. Desplázate desde la vista previa o llamaresetPreview.
6. Lista los IDs de paquetes para esa vista previa.
7. Elimine cada paquete verificado.
8. Elimine el registro de 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 omite 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 incorrecto.

Utilice una regla de concurrencia claveada al número de solicitud de extracción. Cuando un evento de cierre y un evento de reconstrucción lleguen 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 one-command CLI workflow can reduce the number of custom shell calls around build and release work. For command names and supported operations, check the Capgo CLI documentación del comandoUtilice el CLI donde te proporcione una orden verificada. Utilice el SDK o el API público donde las acciones de limpieza requieren una solicitud directa.

Establezca un fallback de retención también. Si se omite 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 controles más estrictos que el hook de cierre normal. Debe seleccionar solo vistas previas con un dueño claro y un timestamp expirado.

Set a retention fallback too. If a close event is missed, a scheduled job can find previews older than your team’s allowed test window. That job needs stricter safeguards than the normal close hook. It should select only previews with a clear owner and an expired timestamp.

Para GitHub Acciones, mantenga las permisos estrechos y pase solo los valores necesarios por el paso de limpieza. Capgo’s actual GitHub Acciones de integración de documentación explica dónde se almacena el token y cómo el flujo de trabajo se conecta a Capgo.

Por ahora deberías 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 lo suficiente para el desarrollo diario sin hacer que la limpieza sea una escoba ciega.

6: Verificar la Limpieza y Proteger los Rollouts de la Eliminación Accidental

La verificación cierra el Capgo ciclo de limpieza de previsualización de solicitudes de extracción. Una respuesta de eliminación sola no es suficiente para un proceso de lanzamiento seguro.

Después de que se ejecuta el trabajo de limpieza, verifica el canal de visualización de nuevo. Confirma que ya no aparece como una visualización activa. Luego verifica la lista de conjuntos de paquetes para la misma aplicación y filtro. El resultado esperado es que los IDs de los conjuntos de paquetes objetivo han desaparecido mientras que los conjuntos de paquetes de producción permanecen.

Guarde estos valores en la resumen del trabajo:

• Repositorio y número de solicitud de extracción.
• Nombre del canal de visualización.
• Commit SHA used for ownership checks.
• IDs de paquete encontrados.
• IDs de paquete eliminados.
• IDs que devolvieron un error.

Utilice un estado claro. 'Limpio' significa que todos los objetivos verificados han desaparecido. 'Ya está limpio' significa que el recurso no estaba presente 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 un 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. El guardia debe fallar cerrado. 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é paquetes reciben los dispositivos. 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.

Observen tres patrones de falla comunes:

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

Giren la clave de limpieza en un horario establecido por su política de seguridad, y girenla 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 de nota clave: 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.

Solo una orden es útil cuando los guardarropas están claros. Siga la vista previa. Adopte un nombre de canal predecible. Vuelva a liberar los cambios de lanzamiento por separado. Luego, déje que el trabajo de limpieza haga su pequeño trabajo sin tocar el tráfico en vivo.

FAQ

¿Puedo eliminar una solicitud de vista previa de Capgo activa?

No. La vista previa activa debe cambiarse primero, o debe llamar a resetPreview. After the active state clears, run Delete Preview. This rule is the main detail to remember when setting up a Capgo pull request preview cleanup API key in CI.

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

Sí. La acción de 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 la tarea de limpieza Capgo sea más fácil de revisar y más segura 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. Liste los identificadores de paquete, elimine coincidencias verificadas y confirme el resultado. Agregue controles de concurrencia para que un edificio tardío no pueda correr la tarea de limpieza.

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

Las causas habituales son una vista previa activa, un identificador 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, liste sus identificadores de paquete, elimine paquetes verificados y luego elimine la vista previa. Comience con un simulacro 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.