quarkus-verification
affaan-m/everything-claude-code
Comprehensive verification pipeline for Quarkus projects: build, analysis, tests, security scans, native compilation, and health checks.
What is quarkus-verification?
A multi-phase verification loop for Quarkus services that runs build, static analysis, test coverage validation, security scanning, native image compilation, performance testing, and health checks. Use before PRs, after major changes, and pre-deployment to catch issues early.
- Phase 1: Clean build with Maven or Gradle
- Phase 2: Static analysis via Checkstyle, PMD, SpotBugs, and optional SonarQube
- Phase 3: Unit, integration, and API tests with JaCoCo coverage enforcement (80%+ threshold)
- Phase 4: Security scanning with OWASP Dependency-Check, Quarkus audit, and ZAP API testing
- Phase 5: GraalVM native image compilation and smoke testing
- Phase 6: Load testing with K6 to measure response time and throughput
How to install quarkus-verification
npx skills add https://github.com/affaan-m/everything-claude-code --skill quarkus-verificationHow to use quarkus-verification
- 1.Run Phase 1 (Build): Execute `mvn clean verify -DskipTests` or `./gradlew clean assemble -x test` to compile without tests
- 2.Run Phase 2 (Static Analysis): Execute `mvn checkstyle:check pmd:check spotbugs:check` and optionally SonarQube scans
- 3.Run Phase 3 (Tests + Coverage): Execute `mvn clean test` followed by `mvn jacoco:report` and `mvn jacoco:check` to enforce 80% threshold
- 4.Run Phase 4 (Security): Execute `mvn org.owasp:dependency-check-maven:check` and `mvn quarkus:audit` to scan for vulnerabilities
- 5.Run Phase 5 (Native): Execute `mvn package -Dnative` to build native executable and test with `curl http://localhost:8080/q/health/live`
- 6.Run Phase 6 (Performance): Create load-test.js with K6 stages and execute `k6 run load-test.js` to measure response times
- 7.Run Phase 7 (Health): Verify endpoints with `curl http://localhost:8080/q/health/live`, `/ready`, and `/q/metrics`
- 8.Run Phase 8 (Container): Build image with `mvn package -Dquarkus.container-image.build=true` and scan with Trivy or Grype
Use cases
- Verify a Quarkus service before opening a pull request
- Validate compatibility after major dependency upgrades or refactoring
- Pre-deployment checks for staging or production environments
- Ensure test coverage meets organizational thresholds (80%+)
- Confirm native image builds successfully and passes smoke tests
- Quarkus developers and teams
- Backend engineers building microservices
- DevOps engineers managing deployment pipelines
- QA engineers validating service quality
- Security-focused development teams
quarkus-verification FAQ
Stop and fix compilation errors before proceeding. The build must pass cleanly without skipping tests to continue verification.
The default target is 80% line coverage and 70% branch coverage. JaCoCo check enforces these thresholds; adjust in your pom.xml if needed.
Common issues include missing reflection configs (use @RegisterForReflection), missing resources (configure quarkus.native.resources.includes), or JNI dependencies. Add reflection configuration classes as needed.
Yes, the phases are modular. However, skipping security (Phase 4) or testing (Phase 3) is not recommended before production deployments.
Phase 2 includes Checkstyle, PMD, and SpotBugs as standalone alternatives. SonarQube is optional and only runs if configured with valid credentials.
Full instructions (SKILL.md)
Source of truth, from affaan-m/everything-claude-code.
name: quarkus-verification description: "Verification loop for Quarkus projects: build, static analysis, tests with coverage, security scans, native compilation, and diff review before release or PR." metadata: origin: ECC
Quarkus Verification Loop
Run before PRs, after major changes, and pre-deploy.
When to Activate
- Before opening a pull request for a Quarkus service
- After major refactoring or dependency upgrades
- Pre-deployment verification for staging or production
- Running full build → lint → test → security scan → native compilation pipeline
- Validating test coverage meets thresholds (80%+)
- Testing native image compatibility
Phase 1: Build
# Maven
mvn clean verify -DskipTests
# Gradle
./gradlew clean assemble -x test
If build fails, stop and fix compilation errors.
Phase 2: Static Analysis
Checkstyle, PMD, SpotBugs (Maven)
mvn checkstyle:check pmd:check spotbugs:check
SonarQube (if configured)
mvn sonar:sonar \
-Dsonar.projectKey=my-quarkus-project \
-Dsonar.host.url=http://localhost:9000 \
-Dsonar.login=${SONAR_TOKEN}
Common Issues to Address
- Unused imports or variables
- Complex methods (high cyclomatic complexity)
- Potential null pointer dereferences
- Security issues flagged by SpotBugs
Phase 3: Tests + Coverage
# Run all tests
mvn clean test
# Generate coverage report
mvn jacoco:report
# Enforce coverage threshold (80%)
mvn jacoco:check
# Or with Gradle
./gradlew test jacocoTestReport jacocoTestCoverageVerification
Test Categories
Unit Tests
Test service logic with mocked dependencies:
@ExtendWith(MockitoExtension.class)
class UserServiceTest {
@Mock UserRepository userRepository;
@InjectMocks UserService userService;
@Test
void createUser_validInput_returnsUser() {
var dto = new CreateUserDto("Alice", "alice@example.com");
// Panache persist() is void — use 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));
}
}
Integration Tests
Test with real database (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 = "alice@example.com";
userRepository.persist(user);
Optional<User> found = userRepository.findByEmail("alice@example.com");
assertThat(found).isPresent();
assertThat(found.get().name).isEqualTo("Alice");
}
}
API Tests
Test REST endpoints with REST Assured:
@QuarkusTest
class UserResourceTest {
@Test
void createUser_validInput_returns201() {
given()
.contentType(ContentType.JSON)
.body("""
{"name": "Alice", "email": "alice@example.com"}
""")
.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);
}
}
Coverage Report
Check target/site/jacoco/index.html for detailed coverage:
- Overall line coverage (target: 80%+)
- Branch coverage (target: 70%+)
- Identify uncovered critical paths
Phase 4: Security Scanning
Dependency Vulnerabilities (Maven)
mvn org.owasp:dependency-check-maven:check
Review target/dependency-check-report.html for CVEs.
Quarkus Security Audit
# Check vulnerable extensions
mvn quarkus:audit
# List all extensions
mvn quarkus:list-extensions
OWASP ZAP (API Security Testing)
docker run -t owasp/zap2docker-stable zap-api-scan.py \
-t http://localhost:8080/q/openapi \
-f openapi
Common Security Checks
- All secrets in environment variables (not in code)
- Input validation on all endpoints
- Authentication/authorization configured
- CORS properly configured
- Security headers set
- Passwords hashed with BCrypt
- SQL injection protection (parameterized queries)
- Rate limiting on public endpoints
Phase 5: Native Compilation
Test GraalVM native image compatibility:
# Build native executable
mvn package -Dnative
# Or with container
mvn package -Dnative -Dquarkus.native.container-build=true
# Test native executable
./target/*-runner
# Run basic smoke tests
curl http://localhost:8080/q/health/live
curl http://localhost:8080/q/health/ready
Native Image Troubleshooting
Common issues:
- Reflection: Add reflection config for dynamic classes
- Resources: Include resources with
quarkus.native.resources.includes - JNI: Register JNI classes if using native libraries
Example reflection config:
@RegisterForReflection(targets = {MyDynamicClass.class})
public class ReflectionConfiguration {}
Phase 6: Performance Testing
Load Testing with 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,
});
}
Run:
k6 run load-test.js
Metrics to Monitor
- Response time (p50, p95, p99)
- Throughput (requests/sec)
- Error rate
- Memory usage
- CPU usage
Phase 7: Health Checks
# Liveness
curl http://localhost:8080/q/health/live
# Readiness
curl http://localhost:8080/q/health/ready
# All health checks
curl http://localhost:8080/q/health
# Metrics (if enabled)
curl http://localhost:8080/q/metrics
Expected responses:
{
"status": "UP",
"checks": [
{
"name": "Database connection",
"status": "UP"
}
]
}
Phase 8: Container Image Build
# Build container image
mvn package -Dquarkus.container-image.build=true
# Or with specific registry
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
# Test container
docker run -p 8080:8080 myorg/my-quarkus-app:1.0.0
Container Security Scan
# Trivy
trivy image myorg/my-quarkus-app:1.0.0
# Grype
grype myorg/my-quarkus-app:1.0.0
Phase 9: Configuration Validation
# Check all configuration properties
mvn quarkus:info
# List all config sources
curl http://localhost:8080/q/dev/io.quarkus.quarkus-vertx-http/config
Environment-Specific Checks
- Database URLs configured per environment
- Secrets externalized (Vault, env vars)
- Logging levels appropriate
- CORS origins set correctly
- Rate limiting configured
- Monitoring/tracing enabled
Phase 10: Documentation Review
- OpenAPI/Swagger docs up to date (
/q/swagger-ui) - README has setup instructions
- API changes documented
- Migration guide for breaking changes
- Configuration properties documented
Generate OpenAPI spec:
curl http://localhost:8080/q/openapi -o openapi.json
Verification Checklist
Code Quality
- Build passes without warnings
- Static analysis clean (no high/medium issues)
- Code follows team conventions
- No commented-out code or TODOs in PR
Testing
- All tests pass
- Code coverage ≥ 80%
- Integration tests with real database
- Security tests pass
- Performance within acceptable limits
Security
- No dependency vulnerabilities
- Authentication/authorization tested
- Input validation complete
- Secrets not in source code
- Security headers configured
Deployment
- Native compilation successful
- Container image builds
- Health checks respond correctly
- Configuration valid for target environment
Native Image
- Native executable builds
- Native tests pass
- Startup time < 100ms
- Memory footprint acceptable
Automated Verification Script
#!/bin/bash
set -e
echo "=== Phase 1: Build ==="
mvn clean verify -DskipTests
echo "=== Phase 2: Static Analysis ==="
mvn checkstyle:check pmd:check spotbugs:check
echo "=== Phase 3: Tests + Coverage ==="
mvn test jacoco:report jacoco:check
echo "=== Phase 4: Security Scan ==="
mvn org.owasp:dependency-check-maven:check
echo "=== Phase 5: Native Compilation ==="
mvn package -Dnative -Dquarkus.native.container-build=true
echo "=== All Phases Complete ==="
echo "Review reports:"
echo " - Coverage: target/site/jacoco/index.html"
echo " - Security: target/dependency-check-report.html"
echo " - Native: target/*-runner"
CI/CD Integration
GitHub Actions Example
name: Verification
on: [push, pull_request]
jobs:
verify:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Set up JDK 21
uses: actions/setup-java@v3
with:
java-version: '21'
distribution: 'temurin'
- name: Cache Maven packages
uses: actions/cache@v3
with:
path: ~/.m2
key: ${{ runner.os }}-m2-${{ hashFiles('**/pom.xml') }}
- name: Build
run: mvn clean verify -DskipTests
- name: Test with Coverage
run: mvn test jacoco:report jacoco:check
- name: Security Scan
run: mvn org.owasp:dependency-check-maven:check
- name: Upload Coverage
uses: codecov/codecov-action@v3
with:
files: target/site/jacoco/jacoco.xml
Best Practices
- Run verification loop before every PR
- Automate in CI/CD pipeline
- Fix issues immediately; don't accumulate debt
- Keep coverage above 80%
- Update dependencies regularly
- Test native compilation periodically
- Monitor performance trends
- Document breaking changes
- Review security scan results
- Validate configuration for each environment
Related skills
More from affaan-m/everything-claude-code and the wider catalog.

ralphinho-rfc-pipeline
RFC-driven multi-agent DAG execution for large features with quality gates and merge orchestration.

recsys-pipeline-architect
Design composable recommendation, ranking, and feed pipelines using the six-stage Source→Hydrator→Filter→Scorer→Selector→SideEffect framework popularized by xAI's open-sourced For You algorithm. Use this skill whenever the user is building any system that picks "the top K items for a (user, context)" — social feeds, content CMSs, RAG rerankers, task prioritizers, notification triage, search reranking, ad ranking.

redis-patterns
Redis patterns for caching, rate limiting, locks, and pub/sub in production applications.

regex-vs-llm-structured-text
Hybrid parsing framework: use regex for 95%+ of structured text, reserve LLM calls for low-confidence edge cases only.

remotion-video-creation
29 domain-specific best practices for building videos in React with Remotion.

repo-scan
Cross-stack source code audit: classify files, detect embedded libraries, deliver actionable verdicts with interactive HTML reports.