• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

valkyrjaio / valkyrja-starter-app-java / 30415942383
100%

Build:
DEFAULT BRANCH: 26.x
Ran 29 Jul 2026 02:08AM UTC
Jobs 2
Files 35
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

29 Jul 2026 02:06AM UTC coverage: 96.119% (+2.1%) from 94.006%
30415942383

push

github

web-flow
[Http][Grpc] Add jetty, netty, and tomcat entry points with runtime tests (#48)

# Description

Wires every server runtime the framework supports as a runnable entry
point in the starter
application — Jetty, Netty and embedded Tomcat over HTTP, and the same
three over gRPC —
and adds tests that start each real server and exercise it.

Until now only the JDK-backed `app.http.App` (`ExchangeHttp`) was wired,
and nothing proved
end to end that a runtime could actually serve a request. That gap hid
three framework
defects, all since fixed and released in `26.4.0`: a worker that never
wrote the response
back through the runtime's own response object
(valkyrjaio/valkyrja-java#50), a route
collection that never loaded the generated routing data and so answered
every request with
a 404 (valkyrjaio/valkyrja-java#52), and a `LoggerContract` nothing
published, which killed
the throwable-caught path with no response at all
(valkyrjaio/valkyrja-java#56).

Each entry mirrors the existing `app.http.App` / `app.http.CgiApp`: a
`main()` that runs the
shared configuration for its protocol, so only the server driving the
application differs.
The framework declares the runtime SDKs `compileOnly` — the "optional
adapter" philosophy —
so this application supplies jetty-server, netty-codec-http,
tomcat-embed-core and the gRPC
transports itself, in its own build and in every CI build that compiles
the application
sources.

**The end-to-end tests live in `sindri-junit`, not `junit`.** The
`junit` build runs with
`copy-example-sources: true` and compiles the empty `*.example.java`
stubs, so an application
booted there has no routes. `sindri-junit` generates the real `App*Data`
and tests the
application as it actually runs in production, which is what serving a
live request requires
— and it is already a separate CI job, so no new job is needed. These
runtimes need no binary
provisioning: they are ordinary Gradle dependencies.

**What the tests assert.** The four HTTP runtimes ... (continued)

8 of 8 branches covered (100.0%)

Branch coverage included in aggregate %.

314 of 327 relevant lines covered (96.02%)

6.29 hits per line

Jobs
ID Job ID Ran Files Coverage
1 30415942383.1 29 Jul 2026 02:08AM UTC 35
60.79
GitHub Action Run
2 30415942383.2 29 Jul 2026 02:08AM UTC 30
96.15
GitHub Action Run
Source Files on build 30415942383
  • Tree
  • List 35
  • Changed 14
  • Source Changed 0
  • Coverage Changed 14
Coverage ∆ File Lines Relevant Covered Missed Hits/Line Branch Hits Branch Misses
  • Back to Repo
  • Github Actions Build #30415942383
  • 886cd212 on github
  • Prev Build on 26.x (#30330122157)
  • Next Build on 26.x (#30416841121)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE TRIAL · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc