ci: smoke-test Grafana and Prometheus, not just the collector (#78)

[tschm]

Fixes #78.

Done when: an image whose Grafana starts but cannot provision the jq-fleet dashboard fails the "image builds and comes up" job.

The "It comes up" step now publishes 9090 and 3000 as well as 9109. A new step after it, "Prometheus scrapes it and Grafana serves the board", waits on:

1. Prometheus /-/ready
2. Grafana /api/health
3. /api/dashboards/uid/jq-fleet, which must return 200 with at least one panel (the board is provisioned, not just Grafana running)
4. /api/datasources/uid/jq-prometheus/health, which must return "status":"OK", so Grafana can reach Prometheus
5. up{job="jq-collector"} = 1, so Prometheus 3 still reads prometheus.yml and scrapes the collector

Every wait gives up early, printing docker logs, if the container exits.

Verified locally, running this step's script from the workflow with only the ports remapped:

Image	Result
this branch, as built	pass: "Jebel-Quant Fleet 28 panels", datasource OK, collector scraped within about 12s
same image, empty dir mounted over /etc/grafana/dashboards	fail: timed out waiting for …/api/dashboards/uid/jq-fleet (404), while docker ps reported the container healthy

The second row is the case the issue describes. Grafana keeps running without the board, so neither the healthcheck nor the entrypoint's "any exit stops the container" rule catches it.

This run also answers the open question from #75: Grafana 13.2.3 and Prometheus 3.15.0 serve the board correctly, with no error lines from either in the logs.

Gates

• prek run --all-files: all hooks pass, including actionlint (with shellcheck over the new run: block).

Closes #78

🤖 Generated with Claude Code