Circleci Jacoco
A circleci jacoco setup runs Java tests in your build pipeline and measures code coverage. You add the coverage tool to your build script and save the output reports. Engineering teams use this workflow to check code quality on every pull request. Many teams also give their build runners broad database keys to run integration tests. Those wide permissions create risk if a test script runs a bad query. How a circleci jacoco workflow operates in your pipeline The build runner starts a clean con
CircleCI Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A circleci jacoco setup runs Java tests in your build pipeline and measures code coverage. You add the coverage tool to your build script and save the output reports. Engineering teams use this workflow to check code quality on every pull request. Many teams also give their build runners broad database keys to run integration tests. Those wide permissions create risk if a test script runs a bad query.
How a circleci jacoco workflow operates in your pipeline
The build runner starts a clean container when a developer pushes new Java code. It pulls the source repo and downloads all project dependencies from your package store. Next, the build tool compiles the Java classes and starts the test suite.
During the test run, the coverage agent attaches to the Java runtime. It watches which lines and branches of code execute during your unit tests. When the tests finish, the agent writes raw execution data to a file.
A report task then reads that raw file and compares it against your source code. It generates human-readable web pages and structured data files that show coverage scores. The pipeline saves these files as build artifacts so developers can read them later. You can also send the structured summary to an external code quality service.
Combining unit tests and database integration checks
Unit tests only check isolated classes and mock out external systems. To get high coverage across data layers, teams run integration tests during the build. The pipeline spins up a test database or connects to a shared staging instance.
The coverage agent tracks code paths while the app runs real queries against the database. It combines the unit test results and the integration test results into one report. This gives the team a complete view of how well they test their code. You can set rules in the build tool to fail the job if coverage drops.
CircleCI Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What the native setup solves and what it leaves open
This pipeline workflow solves the problem of tracking untested Java code before release. It gives reviewers clear numbers on line and branch coverage for every single commit. Teams catch missing tests early and keep their codebase stable over time.
Still, the pipeline setup only controls which jobs run and where reports go. It does not control what the build runner does inside your shared test databases. Teams often store long-lived database keys in pipeline variables so tests can log in.
Once the runner logs in, the native setup cannot check individual queries in flight. A broken test script can drop a shared staging table or read sensitive test data. If staging holds real emails or card numbers, test logs might print those raw values. The pipeline decides who logs in, not what commands run during the session.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
How do I view my coverage reports after the build finishes?
You configure your pipeline job to store the generated report folder as a build artifact. After the job runs, you can open the web report right from the build page.
Can I fail the pipeline build if code coverage is too low?
Yes, the coverage plugin lets you set minimum rules for lines and branches. If the test run falls below your target, the build tool returns an error code.
How do I merge coverage data from parallel test containers?
You save the raw execution file from each parallel container to a shared workspace. A final job then reads all those files and builds one combined report.