Ejecuta pruebas de Apidog CLI en Harness añadiendo una etapa de CI con un solo paso de ejecución (Run step) que instala apidog-cli, ejecuta apidog run y publica los resultados de JUnit. Almacena tu token de acceso de Apidog como un secreto de Harness, haz referencia a él con la expresión <+secrets.getValue("...")> y apunta un bloque de informe de JUnit a la salida XML de la CLI. Esta guía te proporciona YAML de pipeline listo para copiar y pegar, tanto para Harness Cloud como para un delegado autoalojado.
¿Qué es Harness CI/CD?
Harness CI es el módulo de integración continua de la plataforma Harness. Construye, prueba y valida tu código en una infraestructura de compilación gestionada o autoalojada, y luego entrega los artefactos a Harness CD para su despliegue.
Lo defines todo como YAML. Un pipeline contiene una o más etapas. Cada etapa tiene un tipo, y una etapa de CI se ejecuta en la infraestructura de compilación. Dentro de la etapa, un bloque de ejecución contiene una lista ordenada de pasos que ejecutan tus comandos.
El modelo se adapta perfectamente a las pruebas de API. Añades una etapa de CI, incluyes un paso que ejecuta tu comando de prueba y dejas que Harness controle la compilación según el resultado. Si las pruebas fallan, el paso falla y el pipeline se detiene.
Harness lee XML de JUnit para los informes de prueba. Dado que Apidog CLI puede emitir JUnit, obtienes una pestaña de Pruebas nativa con recuentos de aprobaciones y fallos en cada compilación. No se requiere código adicional.
Cómo funciona Harness CI
La jerarquía de YAML es estricta, por lo que ayuda ver el anidamiento antes de escribir cualquier cosa. Un pipeline de CI se ve así de arriba abajo:
pipelinecontiene metadatos y una lista destages.- Cada
stagetiene untype: CIy unspec. - El
specde la etapa declara la infraestructura de compilación y un bloqueexecution. executioncontiene una lista desteps.- Cada
steptiene untype,name,identifiery su propiospec.
Para ejecutar un comando de shell, el tipo de paso es Run. El spec del paso Run contiene un campo shell (Bash, Sh, PowerShell, Pwsh o Python) y un campo command que contiene tu script. Escribes comandos de varias líneas con el escalar de bloque YAML |-.
Ese único paso Run es todo lo que necesitas para instalar y ejecutar Apidog CLI. Todo lo demás en esta guía es configuración alrededor de ese único paso.
Apidog CLI en un minuto
La Apidog CLI es un ejecutor de línea de comandos para escenarios de prueba que construyes visualmente en Apidog. Diseñas las pruebas en la aplicación y luego las ejecutas sin interfaz gráfica en cualquier pipeline, de forma similar a cómo Newman ejecuta colecciones de Postman. Si quieres una comparación lado a lado, consulta Apidog CLI vs Newman.
Lo instalas desde npm y ejecutas un solo comando:
npm install -g apidog-cli
apidog run --access-token <ACCESS_TOKEN> -t <TEST_SCENARIO_ID> -e <ENVIRONMENT_ID> -r cli,junit --out-dir ./apidog-reports
Algunas banderas son importantes para CI. La bandera --access-token autentica la ejecución en la nube y no tiene forma abreviada. La bandera -e establece el entorno y es obligatoria. La bandera -t selecciona un escenario de prueba por ID. La bandera -r elige los reporteros, y junit es uno de los valores soportados (cli, html, json, junit). La bandera --out-dir controla dónde se guardan los informes, con un valor predeterminado de ./apidog-reports.
Esa elección de -r cli,junit es el puente hacia Harness. La CLI escribe el XML de JUnit en el directorio de salida, y Harness lo lee directamente. Para más información sobre lo que produce la CLI, consulta la guía de informes de prueba de Apidog CLI.
Almacenar tu token de acceso de Apidog como un secreto de Harness
Nunca codifiques el token directamente en YAML. Primero, añádelo al gestor de secretos de Harness y luego haz referencia a él.
En la interfaz de usuario de Harness, ve a la configuración de tu proyecto (u organización/cuenta), abre Secretos y crea un nuevo secreto de tipo Texto. Dale el identificador apidog_token. El identificador es lo que referencias en YAML, y difiere del nombre de visualización.
Haces referencia al secreto con esta expresión:
<+secrets.getValue("apidog_token")>
Usa el identificador dentro de las comillas, no el nombre de visualización. Para un secreto con alcance de organización, anteponle org. como <+secrets.getValue("org.apidog_token")>. Para un secreto con alcance de cuenta, usa account. en su lugar.
Envuelve la expresión entre comillas simples dentro de un comando de shell. El token podría contener un carácter $, y las comillas simples impiden que el shell lo expanda. Puedes leer más sobre la configuración de tokens en las notas de autenticación de Apidog CLI.
Pipeline de Harness Cloud (punto de partida recomendado)
Harness Cloud te proporciona máquinas de compilación gestionadas por Harness con Node.js y npm preinstalados. No hay infraestructura que mantener, y Linux funciona de forma predeterminada. Esta es la forma más rápida de obtener un pipeline en funcionamiento.
En Harness Cloud, el spec de la etapa usa un bloque platform y un bloque runtime de type: Cloud. Aquí no especificas una image en el paso Run, ya que la máquina gestionada ya tiene las herramientas.
pipeline:
name: Apidog API Tests
identifier: apidog_api_tests
projectIdentifier: YOUR_PROJECT
orgIdentifier: YOUR_ORG
stages:
- stage:
name: API Tests
identifier: api_tests
type: CI
spec:
cloneCodebase: false
platform:
os: Linux
arch: Amd64
runtime:
type: Cloud
spec: {}
execution:
steps:
- step:
type: Run
name: Run Apidog CLI Tests
identifier: run_apidog_cli_tests
spec:
shell: Sh
command: |-
npm install -g apidog-cli
apidog run \
--access-token '<+secrets.getValue("apidog_token")>' \
-t 605067 \
-e 1629989 \
-n 1 \
-r cli,junit \
--out-dir ./apidog-reports
reports:
type: JUnit
spec:
paths:
- apidog-reports/*.xml
Reemplaza 605067 con tu ID de escenario de prueba y 1629989 con tu ID de entorno. La bandera -n 1 ejecuta una iteración. Configura cloneCodebase: false porque las pruebas residen en la nube de Apidog, por lo que el pipeline no necesita tu repositorio.
Publicar resultados de pruebas
El bloque reports en el paso Run es lo que muestra los resultados en Harness. Toma un type de JUnit y un spec con una lista paths que apunta a tus archivos XML.
reports:
type: JUnit
spec:
paths:
- apidog-reports/*.xml
Harness solo analiza JUnit XML para informes nativos. Después de la compilación, verás una pestaña de Pruebas con cada escenario, su estado y tiempo. El patrón glob apidog-reports/*.xml coincide con los archivos que la CLI escribió con -r cli,junit en el directorio de salida predeterminado.
Harness también ofrece Test Intelligence, que utiliza un tipo de paso Test separado para ejecutar solo las pruebas afectadas por un cambio de código. Esa optimización se dirige a las pruebas unitarias a nivel de lenguaje, no a los escenarios de API sin interfaz gráfica. Para ingerir la salida de Apidog CLI, el paso Run simple con un bloque reports de JUnit es el camino correcto.
Si alguna vez cambias los reporteros, mantén al menos junit en la lista -r. Sin él, la CLI no escribe ningún XML, y la pestaña de Pruebas permanece vacía incluso cuando el propio paso se aprueba.
Alternativa de delegado autoalojado
Utiliza una compilación respaldada por un delegado cuando necesites acceso a una red privada, un tiempo de ejecución personalizado o heredado, o si deseas evitar los créditos de compilación de Harness Cloud. Un delegado de Kubernetes ejecuta cada etapa como un pod.
La estructura cambia de dos maneras. El spec de la etapa usa un bloque infrastructure en lugar de platform y runtime. Y en la infraestructura de Kubernetes, cada paso Run debe declarar un connectorRef y una image, porque el paso se ejecuta dentro de un contenedor que especificas.
spec:
cloneCodebase: false
infrastructure:
type: KubernetesDirect
spec:
connectorRef: YOUR_K8S_CONNECTOR
namespace: harness-ci
execution:
steps:
- step:
type: Run
name: Run Apidog CLI Tests
identifier: run_apidog_cli_tests
spec:
connectorRef: YOUR_DOCKER_CONNECTOR
image: node:20
shell: Sh
command: |-
npm install -g apidog-cli
apidog run \
--access-token '<+secrets.getValue("apidog_token")>' \
-t 605067 -e 1629989 -r cli,junit --out-dir ./apidog-reports
reports:
type: JUnit
spec:
paths:
- apidog-reports/*.xml
La línea image: node:20 te proporciona Node.js y npm dentro del pod. Los valores de connectorRef apuntan a tus conectores registrados de Kubernetes y Docker. No mezcles los dos estilos de infraestructura en una misma etapa. Una etapa es o bien Harness Cloud (platform más runtime) o bien respaldada por un delegado (infrastructure), nunca ambas.
Elegir Harness Cloud vs. un delegado
Elige en función de dónde residen tus API y quién posee las máquinas de compilación.
| Factor | Harness Cloud | Delegado autoalojado |
|---|---|---|
| Configuración | Infraestructura cero, npm preinstalado | Usted gestiona el clúster o las VM |
| Alcance de red | Puntos finales públicos | Puntos finales privados e internos |
| El paso de ejecución necesita imagen | No | Sí, en infraestructura Kubernetes |
| Modelo de costos | Usa créditos de compilación | Su propia computación |
| Mejor para | APIs en la nube, inicio rápido | APIs internas, tiempos de ejecución personalizados |
Empieza con Harness Cloud si tu entorno Apidog accede a puntos finales públicos. Pásate a un delegado cuando tu entorno de prueba esté detrás de una VPN o necesite un tiempo de ejecución que controles. El paso Run y el comando Apidog permanecen casi idénticos entre ambos.
Ejecuciones impulsadas por datos
Puedes alimentar un archivo CSV o JSON en la ejecución para pruebas parametrizadas. La bandera -d (nombre largo --iteration-data) toma la ruta del archivo de datos, y -n establece el recuento de iteraciones.
apidog run --access-token <ACCESS_TOKEN> -t <TEST_SCENARIO_ID> -e <ENVIRONMENT_ID> -d ./data.csv -n 5 -r cli,junit --out-dir ./apidog-reports
Esto ejecuta el escenario una vez por cada fila de datos. En un paso Run de Harness, primero clonarías con `git clone` o prepararías el archivo de datos, y luego apuntarías `-d` a su ruta. Para ver el patrón completo, consulta la prueba de Apidog CLI impulsada por datos y la guía más amplia de pruebas de API automatizadas.
Por qué diseñar las pruebas primero en Apidog
La CLI solo ejecuta escenarios que ya existen en tu proyecto Apidog. Ese es el punto. Apidog es una plataforma de API todo en uno para diseño, depuración, pruebas, simulación y documentación, por lo que construyes tu suite de pruebas una vez y la reutilizas en todas partes.
Diseñas pruebas con un constructor visual, sin necesidad de scripting. Encadenas solicitudes, extraes valores de una respuesta a la siguiente y añades aserciones a través de una interfaz de usuario. La CLI luego ejecuta esa suite exacta sin interfaz gráfica en Harness, de modo que lo que depuras localmente es lo que se ejecuta en el pipeline.
Debido a que Apidog es nativo de OpenAPI con soporte de ramas y espacios de trabajo de equipo, tus ingenieros de QA y desarrolladores backend comparten una fuente única de verdad. Un escenario aprobado en una rama se convierte en el mismo escenario que ejecuta tu comando apidog run. Para patrones de pipeline más amplios, la guía introductoria qué es CI/CD y la guía de flujo de trabajo de GitHub Actions cubren la misma CLI en otros sistemas. El tutorial de Jenkins en integrar pruebas de Apidog con Jenkins utiliza la forma idéntica de comando.
Descarga Apidog gratis para construir tu primer escenario de prueba, luego intégralo en Harness con el YAML anterior.
Preguntas Frecuentes
¿Qué es Harness CI/CD?
Harness CI/CD es una plataforma de pipeline para construir, probar y desplegar software. Defines pipelines como YAML compuestos por etapas y pasos. Una etapa de CI se ejecuta en una infraestructura de compilación, ya sean máquinas Cloud gestionadas por Harness o un delegado autoalojado, y una etapa de CD gestiona el despliegue.
¿Cómo funciona Harness CI?
Un pipeline contiene una lista de etapas. Cada etapa de CI tiene un `spec` que declara la infraestructura de compilación y un bloque de ejecución. El bloque de ejecución corre una lista ordenada de pasos. Un paso Run ejecuta un comando de shell, que es donde instalas y ejecutas Apidog CLI.
¿Cómo se almacenan y usan los secretos en Harness?
Crea un secreto de tipo Texto en el gestor de secretos de Harness y anota su identificador. Haz referencia a él en YAML con <+secrets.getValue("identifier")>, utilizando el identificador en lugar del nombre de visualización. Antepone org. o account. para esos alcances, y envuelve la expresión entre comillas simples dentro de los comandos de shell.
¿Cómo se publican los resultados de las pruebas en Harness?
Añade un bloque reports a tu paso Run con type: JUnit y una lista paths que apunte a tus archivos XML. Harness analiza el JUnit XML y muestra los resultados en la pestaña de Pruebas de la compilación. Apidog CLI emite este XML cuando pasas -r junit o -r cli,junit.
¿Es gratis Harness CI?
Harness ofrece un nivel gratuito para CI, y las compilaciones de Harness Cloud consumen créditos de compilación incluidos en tu plan. Los precios y los límites de crédito cambian con el tiempo, así que consulta la página de precios actual de Harness para obtener cifras exactas antes de comprometerte con un nivel.
¿Puedo ejecutar pruebas de Apidog CLI sin clonar mi repositorio?
Sí. Establece cloneCodebase: false en la etapa cuando tus pruebas residan en la nube de Apidog. La CLI se autentica con tu token de acceso y extrae el escenario y el entorno por ID, por lo que el pipeline nunca necesita tu código fuente para la ejecución de la prueba.