chore(caddy): bump the go-modules group in /caddy with 2 updates

[dependabot]

Bumps the go-modules group in /caddy with 2 updates: github.com/dunglas/mercure and github.com/dunglas/mercure/caddy.

Updates github.com/dunglas/mercure from 0.22.1 to 0.23.0

Release notes

Sourced from github.com/dunglas/mercure's releases.

helm-chart-0.23.0

A Helm chart to install a Mercure Hub in a Kubernetes cluster. Mercure is a protocol to push data updates to web browsers and other HTTP clients in a convenient, fast, reliable and battery-efficient way.

v0.23.0

Community

Transport-aware health checks come to Mercure. Kubernetes (and any other orchestrator) can now detect when a hub's transport connection is actually broken, not just that the Caddy process is alive. This is especially valuable for Enterprise deployments backed by Redis, Postgres, Kafka, or Pulsar — but it also brings a small improvement for users of Bolt or the local transport. This release also adds HTTProute support and configurable deployment annotations in the Helm chart.

✨ New Features

• Transport-aware health check endpoints — a new TransportHealthChecker interface that transports can implement, and a new admin.api.mercure_health Caddy admin API module exposing /mercure/health/{ready,live} (aggregate) and /mercure/health/{hub}/{ready,live} (per-hub) endpoints. Hubs can be named via the new name Caddyfile directive. The Helm chart now enables transport-aware probes by default, with fallback to the legacy /healthz when healthCheck.enabled=false. The /healthz endpoint on the HTTP port is now deprecated — it only reflects that Caddy is running, not transport connectivity. Transports that don't implement the interface (Bolt, Local) are considered always-healthy. by @​dunglas in #1201
• Helm: Add support for HTTProute as an alternative to Ingress for Gateway API-based clusters by @​dunglas in #1122
• Helm: Allow configuring annotations on the Deployment resource by @​vmignot in #1160

Enterprise

All Enterprise transports — Redis, Postgres, Kafka, and Pulsar — now implement the new TransportHealthChecker interface, so the new /mercure/health/{ready,live} endpoints report actual transport connectivity and not just process liveness. This is the main reason the feature was built: production clusters using managed brokers finally get accurate readiness/liveness signals.

If you'd like to try Mercure Enterprise in your cluster, reach out to contact@mercure.rocks for access, SLA-backed support, or the managed Cloud offering.

💖 New Contributors

• @​vmignot made their first contribution in #1160

Full Changelog: dunglas/mercure@v0.22.1...v0.23.0

Commits

• 7193c85 chore: prepare release 0.23.0
• dd07e33 feat(chart): add annotations for deployment (#1160)
• 934ad22 chore: better preflight checks in release.sh (#1205)
• f532ae9 chore: bump dependencies and fix deprecated cmd build tags (#1204)
• 0869f2d feat(helm): add support for HTTProute (#1122)
• c20e815 feat(transport): add transport-aware health check endpoints (#1201)
• 425639e ci: fix zizmor workflow audit findings (#1202)
• See full diff in compare view

Updates github.com/dunglas/mercure/caddy from 0.22.1 to 0.23.0

Release notes

Sourced from github.com/dunglas/mercure/caddy's releases.

helm-chart-0.23.0

A Helm chart to install a Mercure Hub in a Kubernetes cluster. Mercure is a protocol to push data updates to web browsers and other HTTP clients in a convenient, fast, reliable and battery-efficient way.

v0.23.0

Community

Transport-aware health checks come to Mercure. Kubernetes (and any other orchestrator) can now detect when a hub's transport connection is actually broken, not just that the Caddy process is alive. This is especially valuable for Enterprise deployments backed by Redis, Postgres, Kafka, or Pulsar — but it also brings a small improvement for users of Bolt or the local transport. This release also adds HTTProute support and configurable deployment annotations in the Helm chart.

✨ New Features

• Transport-aware health check endpoints — a new TransportHealthChecker interface that transports can implement, and a new admin.api.mercure_health Caddy admin API module exposing /mercure/health/{ready,live} (aggregate) and /mercure/health/{hub}/{ready,live} (per-hub) endpoints. Hubs can be named via the new name Caddyfile directive. The Helm chart now enables transport-aware probes by default, with fallback to the legacy /healthz when healthCheck.enabled=false. The /healthz endpoint on the HTTP port is now deprecated — it only reflects that Caddy is running, not transport connectivity. Transports that don't implement the interface (Bolt, Local) are considered always-healthy. by @​dunglas in #1201
• Helm: Add support for HTTProute as an alternative to Ingress for Gateway API-based clusters by @​dunglas in #1122
• Helm: Allow configuring annotations on the Deployment resource by @​vmignot in #1160

Enterprise

All Enterprise transports — Redis, Postgres, Kafka, and Pulsar — now implement the new TransportHealthChecker interface, so the new /mercure/health/{ready,live} endpoints report actual transport connectivity and not just process liveness. This is the main reason the feature was built: production clusters using managed brokers finally get accurate readiness/liveness signals.

If you'd like to try Mercure Enterprise in your cluster, reach out to contact@mercure.rocks for access, SLA-backed support, or the managed Cloud offering.

💖 New Contributors

• @​vmignot made their first contribution in #1160

Full Changelog: dunglas/mercure@v0.22.1...v0.23.0

Commits

• 7193c85 chore: prepare release 0.23.0
• dd07e33 feat(chart): add annotations for deployment (#1160)
• 934ad22 chore: better preflight checks in release.sh (#1205)
• f532ae9 chore: bump dependencies and fix deprecated cmd build tags (#1204)
• 0869f2d feat(helm): add support for HTTProute (#1122)
• c20e815 feat(transport): add transport-aware health check endpoints (#1201)
• 425639e ci: fix zizmor workflow audit findings (#1202)
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions