Communitygithub.com

verificación-quarkus

Bucle de verificación para proyectos Quarkus: compilación, análisis estático, pruebas con cobertura, escaneos de seguridad, compilación nativa y revisión de diferencias antes de lanzar o abrir un PR.

¿Qué es verificación-quarkus?

Esta habilidad automatiza un bucle de verificación completo para proyectos Quarkus, diseñado para ejecutarse antes de Pull Requests, después de cambios mayores y antes del despliegue. Cubre desde la compilación y análisis estático (Checkstyle, PMD, SpotBugs, SonarQube), pruebas unitarias, de integración y de API con cobertura (Jacoco), hasta escaneos de seguridad (OWASP Dependency Check, Quarkus audit, OWASP ZAP), compilación nativa con GraalVM, pruebas de rendimiento con K6, health checks, construcción de imágenes Docker y validación de configuración. También incluye un checklist completo de verificación, un script automatizado y ejemplos de integración con CI/CD (GitHub Actions). Es útil para desarrolladores y equipos que quieran garantizar la calidad, seguridad y compatibilidad de sus servicios Quarkus antes de integrarlos o desplegarlos, soportando Maven y Gradle, y proporcionando guías detalladas para cada fase.

Compatible con~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/affaan-m/ECC/tree/main/skills/quarkus-verification

Preguntar en tu IA favorita

Abre un nuevo chat con esta habilidad de agente ya precargada.

Documentación

Bucle de Verificación Quarkus

Ejecutar antes de PRs, después de cambios importantes y antes del despliegue.

Cuándo activarlo

  • Antes de abrir un pull request para un servicio Quarkus
  • Después de una refactorización importante o actualización de dependencias
  • Verificación previa al despliegue en staging o producción
  • Ejecución del pipeline completo: compilación → lint → pruebas → escaneo de seguridad → compilación nativa
  • Validación de que la cobertura de pruebas cumple los umbrales (80%+)
  • Prueba de compatibilidad con imágenes nativas

Fase 1: Compilación

# Maven
mvn clean verify -DskipTests

# Gradle
./gradlew clean assemble -x test

Si la compilación falla, deténgase y corrija los errores de compilación.

Fase 2: Análisis estático

Checkstyle, PMD, SpotBugs (Maven)

mvn checkstyle:check pmd:check spotbugs:check

SonarQube (si está configurado)

mvn sonar:sonar \
  -Dsonar.projectKey=my-quarkus-project \
  -Dsonar.host.url=http://localhost:9000 \
  -Dsonar.login=${SONAR_TOKEN}

Problemas comunes a abordar

  • Importaciones o variables no utilizadas
  • Métodos complejos (alta complejidad ciclomática)
  • Posibles desreferencias de puntero nulo
  • Problemas de seguridad señalados por SpotBugs

Fase 3: Pruebas + Cobertura

# Ejecutar todas las pruebas
mvn clean test

# Generar informe de cobertura
mvn jacoco:report

# Aplicar umbral de cobertura (80%)
mvn jacoco:check

# O con Gradle
./gradlew test jacocoTestReport jacocoTestCoverageVerification

Categorías de pruebas

Pruebas unitarias

Probar la lógica del servicio con dependencias simuladas:

@ExtendWith(MockitoExtension.class)
class UserServiceTest {
  @Mock UserRepository userRepository;
  @InjectMocks UserService userService;

  @Test
  void createUser_validInput_returnsUser() {
    var dto = new CreateUserDto("Alice", "[email protected]");

    // Panache persist() es void — usar doNothing + verify
    doNothing().when(userRepository).persist(any(User.class));

    User result = userService.create(dto);

    assertThat(result.name).isEqualTo("Alice");
    verify(userRepository).persist(any(User.class));
  }
}

Pruebas de integración

Probar con base de datos real (Testcontainers):

@QuarkusTest
@QuarkusTestResource(PostgresTestResource.class)
class UserRepositoryIntegrationTest {

  @Inject
  UserRepository userRepository;

  @Test
  @Transactional
  void findByEmail_existingUser_returnsUser() {
    User user = new User();
    user.name = "Alice";
    user.email = "[email protected]";
    userRepository.persist(user);

    Optional<User> found = userRepository.findByEmail("[email protected]");

    assertThat(found).isPresent();
    assertThat(found.get().name).isEqualTo("Alice");
  }
}

Pruebas de API

Probar endpoints REST con REST Assured:

@QuarkusTest
class UserResourceTest {

  @Test
  void createUser_validInput_returns201() {
    given()
        .contentType(ContentType.JSON)
        .body("""
            {"name": "Alice", "email": "[email protected]"}
            """)
        .when().post("/api/users")
        .then()
        .statusCode(201)
        .body("name", equalTo("Alice"));
  }

  @Test
  void createUser_invalidEmail_returns400() {
    given()
        .contentType(ContentType.JSON)
        .body("""
            {"name": "Alice", "email": "invalid"}
            """)
        .when().post("/api/users")
        .then()
        .statusCode(400);
  }
}

Informe de cobertura

Consulte target/site/jacoco/index.html para obtener la cobertura detallada:

  • Cobertura de líneas total (objetivo: 80%+)
  • Cobertura de ramas (objetivo: 70%+)
  • Identificar rutas críticas no cubiertas

Fase 4: Escaneo de seguridad

Vulnerabilidades de dependencias (Maven)

mvn org.owasp:dependency-check-maven:check

Revise target/dependency-check-report.html para ver CVEs.

Auditoría de seguridad de Quarkus

# Comprobar extensiones vulnerables
mvn quarkus:audit

# Listar todas las extensiones
mvn quarkus:list-extensions

OWASP ZAP (Pruebas de seguridad de API)

docker run -t ghcr.io/zaproxy/zaproxy:stable zap-api-scan.py \
  -t http://localhost:8080/q/openapi \
  -f openapi

Comprobaciones de seguridad comunes

  • Todos los secretos en variables de entorno (no en el código)
  • Validación de entrada en todos los endpoints
  • Autenticación/autorización configurada
  • CORS configurado correctamente
  • Cabeceras de seguridad configuradas
  • Contraseñas hasheadas con BCrypt
  • Protección contra inyección SQL (consultas parametrizadas)
  • Limitación de velocidad en endpoints públicos

Fase 5: Compilación nativa

Pruebe la compatibilidad con la imagen nativa de GraalVM:

# Compilar ejecutable nativo
mvn package -Dnative

# O con contenedor
mvn package -Dnative -Dquarkus.native.container-build=true

# Probar ejecutable nativo
./target/*-runner

# Ejecutar pruebas de humo básicas
curl http://localhost:8080/q/health/live
curl http://localhost:8080/q/health/ready

Solución de problemas de imágenes nativas

Problemas comunes:

  • Reflexión: Añadir configuración de reflexión para clases dinámicas
  • Recursos: Incluir recursos con quarkus.native.resources.includes
  • JNI: Registrar clases JNI si se usan bibliotecas nativas

Ejemplo de configuración de reflexión:

@RegisterForReflection(targets = {MyDynamicClass.class})
public class ReflectionConfiguration {}

Fase 6: Pruebas de rendimiento

Pruebas de carga con K6

// load-test.js
import http from 'k6/http';
import { check } from 'k6';

export const options = {
  stages: [
    { duration: '30s', target: 50 },
    { duration: '1m', target: 100 },
    { duration: '30s', target: 0 },
  ],
};

export default function () {
  const res = http.get('http://localhost:8080/api/markets');
  check(res, {
    'status is 200': (r) => r.status === 200,
    'response time < 200ms': (r) => r.timings.duration < 200,
  });
}

Ejecutar:

k6 run load-test.js

Métricas a monitorizar

  • Tiempo de respuesta (p50, p95, p99)
  • Rendimiento (solicitudes/segundo)
  • Tasa de error
  • Uso de memoria
  • Uso de CPU

Fase 7: Health checks

# Liveness
curl http://localhost:8080/q/health/live

# Readiness
curl http://localhost:8080/q/health/ready

# Todos los health checks
curl http://localhost:8080/q/health

# Métricas (si está habilitado)
curl http://localhost:8080/q/metrics

Respuestas esperadas:

{
  "status": "UP",
  "checks": [
    {
      "name": "Database connection",
      "status": "UP"
    }
  ]
}

Fase 8: Construcción de imagen de contenedor

# Construir imagen de contenedor
mvn package -Dquarkus.container-image.build=true

# O con registro específico
mvn package \
  -Dquarkus.container-image.build=true \
  -Dquarkus.container-image.registry=docker.io \
  -Dquarkus.container-image.group=myorg \
  -Dquarkus.container-image.tag=1.0.0

# Probar contenedor
docker run -p 8080:8080 myorg/my-quarkus-app:1.0.0

Escaneo de seguridad del contenedor

# Trivy
trivy image myorg/my-quarkus-app:1.0.0

# Grype
grype myorg/my-quarkus-app:1.0.0

Fase 9: Validación de configuración

# Comprobar todas las propiedades de configuración
mvn quarkus:info

# Listar todas las fuentes de configuración
curl http://localhost:8080/q/dev/io.quarkus.quarkus-vertx-http/config

Comprobaciones específicas del entorno

  • URLs de base de datos configuradas por entorno
  • Secretos externalizados (Vault, variables de entorno)
  • Niveles de registro apropiados
  • Orígenes CORS configurados correctamente
  • Limitación de velocidad configurada
  • Monitorización/trazado habilitado

Fase 10: Revisión de documentación

  • Documentación OpenAPI/Swagger actualizada (/q/swagger-ui)
  • README con instrucciones de configuración
  • Cambios en la API documentados
  • Guía de migración para cambios importantes
  • Propiedades de configuración documentadas

Generar especificación OpenAPI:

curl http://localhost:8080/q/openapi -o openapi.json

Lista de verificación

Calidad del código

  • La compilación pasa sin advertencias
  • Análisis estático limpio (sin problemas altos/medios)
  • El código sigue las convenciones del equipo
  • Sin código comentado ni TODOs en el PR

Pruebas

  • Todas las pruebas pasan
  • Cobertura de código ≥ 80%
  • Pruebas de integración con base de datos real
  • Pruebas de seguridad pasan
  • Rendimiento dentro de límites aceptables

Seguridad

  • Sin vulnerabilidades de dependencias
  • Autenticación/autorización probada
  • Validación de entrada completa
  • Secretos no en el código fuente
  • Cabeceras de seguridad configuradas

Despliegue

  • Compilación nativa exitosa
  • La imagen del contenedor se construye
  • Los health checks responden correctamente
  • Configuración válida para el entorno de destino

Imagen nativa

  • El ejecutable nativo se compila
  • Las pruebas nativas pasan
  • Tiempo de inicio < 100ms
  • Huella de memoria aceptable

Script de verificación automatizado

#!/bin/bash
set -e

echo "=== Fase 1: Compilación ==="
mvn clean verify -DskipTests

echo "=== Fase 2: Análisis estático ==="
mvn checkstyle:check pmd:check spotbugs:check

echo "=== Fase 3: Pruebas + Cobertura ==="
mvn test jacoco:report jacoco:check

echo "=== Fase 4: Escaneo de seguridad ==="
mvn org.owasp:dependency-check-maven:check

echo "=== Fase 5: Compilación nativa ==="
mvn package -Dnative -Dquarkus.native.container-build=true

echo "=== Todas las fases completadas ==="
echo "Revise los informes:"
echo "  - Cobertura: target/site/jacoco/index.html"
echo "  - Seguridad: target/dependency-check-report.html"
echo "  - Nativo: target/*-runner"

Integración con CI/CD

Ejemplo de GitHub Actions

name: Verificación

on: [push, pull_request]

jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7

      - name: Configurar JDK 21
        uses: actions/setup-java@v5
        with:
          java-version: '21'
          distribution: 'temurin'

      - name: Cachear paquetes Maven
        uses: actions/cache@v6
        with:
          path: ~/.m2
          key: ${{ runner.os }}-m2-${{ hashFiles('**/pom.xml') }}

      - name: Compilar
        run: mvn clean verify -DskipTests

      - name: Pruebas con cobertura
        run: mvn test jacoco:report jacoco:check

      - name: Escaneo de seguridad
        run: mvn org.owasp:dependency-check-maven:check

      - name: Subir cobertura
        uses: codecov/codecov-action@v7
        with:
          token: ${{ secrets.CODECOV_TOKEN }}
          files: target/site/jacoco/jacoco.xml

Mejores prácticas

  • Ejecute el bucle de verificación antes de cada PR
  • Automatícelo en el pipeline CI/CD
  • Corrija los problemas inmediatamente; no acumule deuda técnica
  • Mantenga la cobertura por encima del 80%
  • Actualice las dependencias regularmente
  • Pruebe la compilación nativa periódicamente
  • Monitorice las tendencias de rendimiento
  • Documente los cambios importantes
  • Revise los resultados de los escaneos de seguridad
  • Valide la configuración para cada entorno

Individual skills in this repo

This repo contains 20 individual skills — each has its own dedicated page.

accessibility

Design, implement, and audit inclusive digital products using WCAG 2.2 Level AA. Use when building or auditing UI that must meet WCAG 2.2 Level AA, or when reviewing a change for keyboard, contrast, or screen-reader support.

affaan-m/content-engine

Create platform-native content systems for X, LinkedIn, TikTok, YouTube, newsletters, and repurposed multi-platform campaigns. Use when the user wants social posts, threads, scripts, content calendars, or one source asset adapted cleanly across platforms.

affaan-m/ECC

Multi-platform content distribution across X, LinkedIn, Threads, and Bluesky. Adapts content per platform using content-engine patterns. Never posts identical content cross-platform. Use when the user wants to distribute content across social platforms.

affaan-m/fal-ai-media

Unified media generation via fal.ai MCP — image, video, and audio. Covers text-to-image (Nano Banana), text/image-to-video (Seedance, Kling, Veo 3), text-to-speech (CSM-1B), and video-to-audio (ThinkSound). Use when the user wants to generate images, videos, or audio with AI.

affaan-m/manim-video

日本語翻訳:このファイルは manim-video 用の日本語翻訳が必要です

affaan-m/remotion-video-creation

Remotion のベストプラクティス - React で動画を作成する。3D、アニメーション、音声、字幕、チャート、トランジションなどをカバーするドメイン固有の29のルール。

affaan-m/video-editing

AI-assisted video editing workflows for cutting, structuring, and augmenting real footage. Covers the full pipeline from raw capture through FFmpeg, Remotion, ElevenLabs, fal.ai, and final polish in Descript or CapCut. Use when the user wants to edit video, cut footage, create vlogs, or build video content.

agent-architecture-audit

Full-stack diagnostic for agent and LLM applications. Audits the 12-layer agent stack for wrapper regression, memory pollution, tool discipline failures, hidden repair loops, and rendering corruption. Produces severity-ranked findings with code-first fixes. Essential for developers building agent applications, autonomous loops, or any LLM-powered feature. Use when an agent or LLM feature misbehaves and the failing layer is unknown, or before shipping an agent stack.

agent-eval

Head-to-head comparison of coding agents (Claude Code, Aider, Codex, etc.) on custom tasks with pass rate, cost, time, and consistency metrics. Use when choosing between coding agents, or when a change to an agent setup needs measured pass rate, cost, and time rather than an impression.

agent-harness-construction

Design and optimize AI agent action spaces, tool definitions, and observation formatting for higher completion rates. Use when defining or revising an agent

agentic-engineering

Operate as an agentic engineer using eval-first execution, decomposition, and cost-aware model routing. Use when planning or executing engineering work that agents will carry out end to end.

agentic-os

Build persistent multi-agent operating systems on Claude Code. Covers kernel architecture, specialist agents, slash commands, file-based memory, scheduled automation, and state management without external databases. Use when building a persistent multi-agent system on Claude Code with its own memory, commands, and scheduling.

agent-introspection-debugging

Structured self-debugging workflow for AI agent failures using capture, diagnosis, contained recovery, and introspection reports. Use when an agent run fails and you need a reproducible diagnosis instead of a retry.

agent-payment-x402

Add x402 payment execution to AI agents with per-task budgets, spending controls, and non-custodial wallets. Supports Base through agentwallet-sdk and X Layer through OKX Payments / OKX Agent Payments Protocol. Use when an agent must pay for something itself and needs per-task budgets, spending controls, and a non-custodial wallet.

agent-self-evaluation

Use after completing any non-trivial task. The agent self-rates its output on 5 axes — accuracy, completeness, clarity, actionability, conciseness — with concrete evidence per criterion. Produces a structured 1-5 scorecard with specific improvement suggestions.

agent-sort

Build an evidence-backed ECC install plan for a specific repo by sorting skills, commands, rules, hooks, and extras into DAILY vs LIBRARY buckets using parallel repo-aware review passes. Use when ECC should be trimmed to what a project actually needs instead of loading the full bundle.

ai-first-engineering

Engineering operating model for teams where AI agents generate a large share of implementation output. Use when setting team process, review gates, or ownership rules for a codebase largely written by agents.

ai-regression-testing

Regression testing strategies for AI-assisted development. Sandbox-mode API testing without database dependencies, automated bug-check workflows, and patterns to catch AI blind spots where the same model writes and reviews code. Use when adding regression coverage to AI-assisted code, or when the same model both wrote and reviewed a change.

android-clean-architecture

Clean Architecture patterns for Android and Kotlin Multiplatform projects — module structure, dependency rules, UseCases, Repositories, and data layer patterns. Use when structuring modules, layers, or data flow in an Android or KMP project.

angular-developer

Generates Angular code and provides architectural guidance. Trigger when creating projects, components, or services, or for best practices on reactivity (signals, linkedSignal, resource), forms, dependency injection, routing, SSR, accessibility (ARIA), animations, styling (component styles, Tailwind CSS), testing, or CLI tooling.

Skills relacionados