Release freshness dashboard for public GitHub users and orgs.
ReleaseBar tracks public GitHub repository release health: latest version, release date, commits since release, activity, stars, language, topics, open work, CI status, and recent stargazer audience signals. It serves cached dashboards for routes like https://release.bar/steipete, https://release.bar/openclaw, and https://release.bar/microsoft.
Owner dashboards show visible public repositories immediately with lightweight repo metadata, then progressively hydrate release, commit, PR, and CI data in the background.
Edit releasebar.config.json:
owners: GitHub users or orgs to scanincludeForks: include forked repositoriesincludeArchived: include archived repositoriesincludeUnreleased: include repositories without GitHub releases in static buildsexcludeRepos: fullowner/nameentries to hidecanonicalDomain: primary public dashboard domain
npm run buildSet GITHUB_TOKEN for higher API limits. GitHub Actions uses the built-in token. Static builds read releasebar.config.json; the public service reads owner routes through the Worker API.
/loadsReleaseBar Hot, a cached board built from recently requested public dashboards/:ownerloads the Worker API for that owner/:owner/activitygroups day, week, or month public work by repository, ranked by activity volume, with AI summaries and contributor forks of profile-owned repositories omitted when GitHub identifies them- query options:
forks=true,archived=true,unreleased=false - add public sources with
owners=openclaw,steipeteorrepos=owner/name - the settings panel can add public users, orgs, or explicit repos to the current URL
- signed-in dashboard owners can save added public sources and local visibility as the public default for their clean owner route
- custom URLs are capped at 8 added public sources
- settings can hide visible owners or repos locally without changing the shared cache
- GitHub App login uses
/api/auth/login,/api/auth/callback,/api/auth/install,/api/auth/logout, and/api/me Log in with GitHubsigns the user in, detects existing GitHub App installations, and only offers installation when the current dashboard source is not covered- GitHub App installation gives ReleaseBar dedicated GitHub API quota for the selected account/repositories; public unsynced dashboards stay metadata-only and skip release hydration
- repository audience backfill is GitHub App-only and warms bounded week/month stargazer trust caches for covered repositories
- once an account installation is known, public refreshes for that account can use its app quota even for anonymous viewers; mixed-owner dashboards partition work across each source account's installation instead of forcing the whole dashboard onto shared quota
- successful login or installation immediately queues a bounded public owner-dashboard warm for each all-repository installation when its shared cache is missing, stale, or incomplete
- private repositories are ignored even when selected in GitHub App installation; ReleaseBar only stores and renders public repository metadata
- the need-attention metric filters repos with unreleased commits, stale releases, failing/cancelled CI, or issue/PR pressure and rows show the reason inline
- owner pages show bounded people trust or org signal profiles with GitHub age, reach, footprint, safety dimensions, weighted score factors, and recent repository evidence
- repository detail pages include release cadence, recent releases, contributors, languages, commit/churn charts, recent public stargazer audience signals, and 30-day issue/PR trend counts when GitHub provides them
- repository detail pages can show an AI summary of commit titles since the latest release when the Worker has an OpenAI API key
The Worker in worker/index.ts serves both the static app shell and the generic owner API. See docs/api.md for the public REST contract, response shapes, cache semantics, and agent PR-triage guidance.
GET /api/:ownerreturns a cached dashboard for a public GitHub user or orgGET /api/:owner/eventsstreams cache updates for progressive rebuildsGET /api/:owner/activity?range=day|week|monthreturns ranked, grouped public activity and cached AI summariesGET /api/users/:login/trustreturns cached public people trust or organization signal scoring, account age, score dimensions, and weighted score factors for one GitHub profileGET /api/repos/:owner/:reporeturns repository detail statsGET /api/repos/:owner/:repo/audience?range=week|monthreturns cached recent stargazer scoring from public GitHub profile fieldsPOST /api/repos/:owner/:repo/audience/backfillwarms bounded week/month stargazer trust caches with GitHub App quota onlyGET /openapi.json,GET /api/openapi.json, andGET /api/swagger.jsonexpose the public API as Swagger-compatible OpenAPI 3.1 JSONGET /api/_discoverandGET /api/_hotpower the root dashboard
Dashboard builds validate public GitHub owners and scan up to the 200 most recently pushed public repositories per owner. Shared owner metadata snapshots feed every dashboard filter/release variant. Active owners get a lean issue/PR/archive GraphQL refresh about every 15 minutes, while release and CI hydration stays on the roughly six-hour dashboard cadence. Cold dashboards return lightweight repository metadata before release hydration continues through Cloudflare Queue in 12-repository batches, with up to four repositories hydrated concurrently inside each batch. Anonymous REST fallbacks leave split counts unavailable instead of spending one extra request per repository. Unsynced public dashboards show bounded repository metadata without release, compare, commit, or check-run calls. Dashboard payloads expose separate countsUpdatedAt, releasesUpdatedAt, and ciUpdatedAt cache timestamps. Dashboard payloads, owner snapshots, repo fragments, hot boards, app-installation coverage, profile settings, and auth session data live in Cloudflare KV. A Durable Object binding (DASHBOARD_LOCKS) prevents repeated cold requests from stampeding GitHub and stores strongly consistent progressive-scan checkpoints, active-job reservations, and refresh-target failure state between rapid Queue deliveries.
Fresh dashboard cache is served for about 1h. Stale or partial cache is shown while a background rebuild continues, so large owners can show useful rows before all release data finishes. Dashboard records are retained longer than the fresh window so older public data can remain visible during GitHub outages or rate limits, with the UI marking stale/partial state.
GITHUB_TOKEN is the shared fallback bucket for sources without GitHub App coverage. Repository detail caches use conditional ETag revalidation, concurrent cold requests share one build, and signed webhooks evict repository-scoped cache fragments. When the shared core or GraphQL bucket falls below 2,000 remaining requests, nonessential contributor, language, stats, and work-trend enrichment is deferred. Below 1,000 remaining requests, uncached repository detail becomes cache-only until reset; installed accounts continue on their independent App buckets.
The Worker writes structured github_token_use and github_installation_token logs without token values. Use Cloudflare Worker tail/logs to audit which area, route, quota source, account, status, and remaining rate-limit bucket handled public GitHub requests.
Configure these Worker secrets before enabling login:
GITHUB_APP_CLIENT_IDGITHUB_APP_CLIENT_SECRETGITHUB_APP_IDGITHUB_APP_PRIVATE_KEYGITHUB_WEBHOOK_SECRETAUTH_COOKIE_SECRET
GITHUB_APP_ID and GITHUB_APP_PRIVATE_KEY are required for dedicated GitHub App quota. Without them, users can still sign in, but dashboard rebuilds use the shared server token/cache. Optional: GITHUB_APP_SLUG defaults to releasebar-app, the current GitHub App slug.
Set the GitHub App setup URL to https://release.bar/api/auth/install and enable redirect-on-update so users return to their dashboard after installing or changing repository access.
Set the GitHub App webhook URL to https://release.bar/api/github/webhook, use the same value as the GITHUB_WEBHOOK_SECRET Worker secret, and subscribe to Issues, Pull requests, Push, Releases, and Repository events. Signed deliveries up to 2 MiB enter Cloudflare Queue before acknowledgement. Per-owner Durable Objects coalesce issue/PR bursts into one authoritative repository-count refresh and push/release bursts into one release refresh; repository privacy and archive transitions remain distinct and use repository observation clocks. Up to 25 recently viewed matching candidates from the available target indexes enter an immediate batch; fanout waits for that batch to drain, capped at two minutes, before the remaining recent variants follow through a stable key-ordered sweep. Older variants refresh on demand.
Configure OPENAI_API_KEY as a Worker secret to summarize recent public activity and commit titles since the latest release. Optional: OPENAI_SUMMARY_MODEL defaults to chat-latest, OpenAI's GPT-5.5 Instant API alias.
wrangler secret put OPENAI_API_KEYSummaries are generated server-side through the OpenAI Responses API without an explicit reasoning option. Owner activity uses one compact structured request for the overall summary and up to 30 repository summaries, with a repository-aware output ceiling and a compatibility floor for configurable reasoning models. Release summaries are cached by repository, release tag, default-branch head SHA, model, and prompt version; activity summaries also refresh when the configured model changes.
Use Wrangler remote dev when you need local code with real Cloudflare execution, GitHub App secrets, and OpenAI/GitHub tokens:
npm run dev:worker:realOpen http://localhost:8787/steipete or any other route. This runs the current checkout on Cloudflare, so cold dashboards can use the same GitHub App credentials and real API paths as release.bar.
For frontend hot reload, run both processes:
npm run dev
npm run dev:worker:realThe Vite app falls back to http://127.0.0.1:8787 for API calls. npm run dev:worker stays fully local and is useful for UI shape and tests, but it does not have production secrets unless you provide local .dev.vars.
Because wrangler.toml defines a KV preview_id, remote dev uses the preview KV namespace instead of the production cache. It can fetch real data and warm that preview cache without mutating the live release.bar cache.
The combined app/API Worker deploys with Wrangler through .github/workflows/deploy.yml on pushes to main:
npm run build
wrangler deploywrangler.toml binds dist as Worker static assets, DASHBOARD_CACHE as KV, and DASHBOARD_LOCKS as the Durable Object single-flight lock. The Worker runs first so /api/* stays dynamic and owner routes like /openclaw return the app shell with HTTP 200. Deploy CI smokes the root page, an owner page, a repository detail page, the discovery API, and live JS/CSS asset hashes after Wrangler deploys.
.github/workflows/monitor.yml repeats the production route, discovery API, and live asset smoke checks every six hours without redeploying unchanged code.
The deployed Worker service is still named releasedeck-api in Cloudflare for continuity. The canonical product, repo, package, and config names are ReleaseBar / releasebar.