The pinned pnpm 11 in workflow-prepare.sh and ci.yaml cannot switch to the
pnpm 12 native binary. Node runs the binary as JavaScript and the install fails.
The rescan button of one repository now triggers automatic actions too. The webhook calls run in the background so the response does not wait for them.
External contributors open pull requests from forks. The pr_open alert now covers them, so the review action sees them. The consumer must treat fork pull requests as untrusted.
A new pr_open alert carries the head commit SHA of each open, non-draft, same-repository pull request. An action with auto enabled sends its webhook once for each pull request and head commit. An authors list limits which pull requests trigger it. The alert never changes repository health.
Alerts that match a configured action get a button labelled from the
config. A confirm dialog opens first when the action defines confirm text.
After a press the UI posts the alert, reloads the state through the
existing poll path and shows the reported status as a chip, with an anchor
when the status carries a link.
The alert dialog comes from reka-ui through the usual shadcn-vue wrappers.
An optional actions block in the config adds buttons to alerts. POST
/api/actions/{id} checks that the repository and the current alert match,
then sends the alert as JSON to the configured webhook with an optional
bearer token. The request refuses cross-site callers like POST /refresh.
GET /api/state lists the actions and merges per-alert status rows from an
optional status_url, cached for 10 seconds. Without an actions block the
API output does not change.
The ghtracker_action_requests_total counter records each result.
Projects now sort by the newest alert they hold, whether a failing workflow, a waiting pull request or a stale issue. Projects with equal ages keep the server order.
* feat(refresh): refresh a single repository with POST /refresh?repo=
The endpoint refreshes one configured repository and returns the full state plus the repo name.
Each repository has a 60-second cooldown that is separate from the full-refresh limit.
A running full refresh or a refresh of the same repository returns 409.
An unknown repository returns 404. Cross-site and disabled-config behaviour stay the same.
The collector reuses its fetch path and replaces only that repository.
* feat(ui): add a refresh button beside each repository
The button appears in the project list and in each attention group header.
It stays hidden when the server disables manual refresh.
The button shows a spinner while its repository refreshes and reports refusals in the notice line.
The store swaps in the returned state, so no extra fetch follows.
GitHub can answer one exact run-listing query from an old cached result
for weeks. The same query on a new connection returned the same old
failure, so a workflow whose latest runs passed still showed as failing.
The confirmation request now adds page=1. The changed query skips the
cached result and returns current runs. The test models a cache that
serves the plain query only.
When the first scan of a repository failed, the repository link pointed at github.com. It now follows github.api_url: Enterprise Server hosts drop the /api/v3 suffix and Enterprise Cloud hosts drop the api. prefix.
The page follows the kportal page: a hero with the install command, a dashboard walkthrough with screenshots from public repositories, feature rows, the alert rules, install methods, set-up steps, the metric list, a reference, troubleshooting and a FAQ.
A workflow deploys docs/ to GitHub Pages. Changes under docs/ no longer start a release.
GitHub sometimes answers a workflow run listing from a lagging replica. For one workflow the answer held 135 runs and ended three weeks ago, while the current listing held 414 runs. The client reuses one connection, so a stale replica could answer every request of a scan and the dashboard showed a failure that a newer run had already replaced.
A failing workflow is now requested again on a new connection that skips the response cache. The client keeps the union of both answers, so the newest run decides.
The loading screen shows live scan progress from the server, with a pulsing outline of the dashboard. The server now reports how many repositories the running scan has finished.
The project list renders 20 rows first and adds more as the end scrolls into view. Groups on very wide screens fill two balanced columns, the fact figures sit in a row under the health strip, and the headline counts match the rows listed below it.
The page no longer caps its width. On very wide screens the attention list shows two columns of projects.
On phones the header, the health strip and the filter chips wrap or scroll inside their own box, and each item shows its age under the text. The side panel scrolls on its own.
The module declared Go 1.27.1, which the release workflow runners do not have. The code needs Go 1.25 at most, so the module now declares that version.
ghtracker authenticates as a GitHub App and scans a configured list of repositories on a schedule. It serves a dashboard, a JSON state endpoint, a health probe and Prometheus metrics.
The dashboard lists only items that need attention: failing workflows, pull requests that wait too long or fail their checks, stale issues and projects that failed to scan. It has search, dynamic filters and a button that rescans on demand. The Vue app is embedded in the Go binary.
The client protects the GitHub rate limit with conditional requests, a request reserve and Retry-After handling.
lukaszraczylo
