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

stacklok / toolhive / 40898763317
73%

Build:
DEFAULT BRANCH: main
Ran 29 Oct 2026 03:18PM UTC
Jobs 1
Files 987
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 Oct 2026 03:09PM UTC coverage: 72.053% (-0.007%) from 72.06%
40898763317

push

github

web-flow
Wire configured delegate clients into the runner (#6953)

* Share embedded auth server test helper

The delegate client integration tests each repeated the code that starts
an embedded auth server on a loopback listener with a mock upstream and
registers its cleanup. Move it into one helper that takes a config
callback and optional storage, and make the runner and restart tests thin
wrappers over it. Their behaviour is unchanged, except that the restart
test's 30-second construction timeout now applies to every caller.

Co-authored-by: Mecatl <noreply@mecatl.dev>

* Wire configured client auth fields into runner

The configured delegate client fields were validated but never reached
the running server. The runner now reads each jwks_file next to the
client secret handling and passes keys, auth method, grants and
redirect URIs to the client constructor. A jwks_file with more than one
key must give every key a unique kid, and the client must send the kid
of its signing key: fosite checks an assertion without a kid only
against the first signing key of its type, so a key added during a
rotation could not be used otherwise.

Discovery advertises private_key_jwt when a configured client uses it,
and the client_secret_* methods only when confidential DCR is on or a
configured client authenticates with a secret. The cleartext-transport
rule is unchanged: every delegate client, private_key_jwt ones
included, still counts as confidential there.

With grant_types wired through, a configured client can hold grants
other than token exchange and still lack authorization_code. /authorize
now treats every client without authorization_code as back-channel
only and answers invalid_client, as for an unknown client, so the
client's existence cannot be probed. It deliberately does not use
unauthorized_client (RFC 6749 section 4.1.2.1) for the same reason.

Delegate clients are built and checked as consent-exempt before they
are written, and the built delegate wins over a... (continued)

128 of 131 new or added lines in 10 files covered. (97.71%)

322 existing lines in 4 files now uncovered.

90779 of 125990 relevant lines covered (72.05%)

130.78 hits per line

Uncovered Changes

Lines Coverage ∆ File
3
81.44
0.64% pkg/authserver/server_impl.go

Coverage Regressions

Lines Coverage ∆ File
266
83.7
0.0% pkg/authserver/storage/redis.go
47
59.31
-4.58% pkg/workloads/manager.go
6
19.87
-3.97% pkg/client/manager.go
3
0.0
-100.0% pkg/workloads/sysproc_unix.go
Jobs
ID Job ID Ran Files Coverage
1 40898763317.1 29 Oct 2026 03:18PM UTC 987
72.05
GitHub Action Run
Source Files on build 40898763317
  • Tree
  • List 987
  • Changed 21
  • Source Changed 16
  • Coverage Changed 19
Coverage ∆ File Lines Relevant Covered Missed Hits/Line
  • Back to Repo
  • Github Actions Build #40898763317
  • d321ebda on github
  • Prev Build on main (#40766101900)
  • Next Build on main (#40946339513)
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