No permanent backend
Collection runs in GitHub Actions and produces a JSON snapshot embedded in the Pages artifact.
Architectural case study · engineering intelligence
Turn dozens of repositories into an observable portfolio without creating another backend to operate.
Repo Control Center started from a simple operational problem: as the number of repositories grows, CI, delivery, releases, security, packages, and activity become too scattered to form a reliable view of the whole. The solution collects evidence outside the browser, makes incomplete information explicit, and publishes a static snapshot for inspection.
The dashboard is read-only. Tokens used for collection remain inside GitHub Actions and are never sent to the published SPA.
Problem
GitHub has the signals, but it does not provide an operational portfolio view as one system.
Builds, deployments, releases, activity, alerts, packages, and open work exist across different surfaces and APIs. Opening repositories one by one works while the set is small; beyond that point, finding context becomes operational overhead itself.
The challenge was not simply to build another visual dashboard. It was to establish a common language for repository state without turning missing data into failure, and without adding permanent infrastructure just to aggregate signals that change at a relatively low frequency.
Constraints and quality attributes
The architecture starts from data confidence and acceptable operational cost.
No browser credentials
The SPA consumes static data only. Tokens and permissions remain inside the automation environment.
Incomplete data is a valid state
Each repository reports complete, partial, or unavailable collection plus confidence derived from source coverage.
One failed source must not stop the portfolio
Optional queries may fail without blocking publication of the remaining repositories; degradation remains explicit.
OperabilityObservabilitySecurityData confidenceLow costEvolvability
Architectural decisions
The design separates privileged collection, data contract, and public presentation.
GitHub Actions as the collection process
The Node.js collector queries APIs during the workflow, paginates responses, bounds concurrency, and normalizes evidence before publication.
Trade-off: updates are periodic rather than real-time.
Static snapshot as the boundary
The published JSON decouples the SPA from authenticated APIs and turns collection into a reproducible read contract.
Trade-off: the UI represents the last successful workflow state.
Angular SPA on GitHub Pages
The interface provides filters, search, repository details, and aggregate insights without an application service running continuously.
Trade-off: detailed routes use hashes and all content depends on the published snapshot.
Confidence separated from health
complete, partial, and unavailable describe collection observability; repository health remains a separate classification.
Trade-off: the UI must communicate uncertainty instead of collapsing everything into one color.
Semantic workflow classification
CI, quality, security, mutation, delivery, release, Pages, and maintenance represent different roles; only the appropriate signal should affect build and delivery status.
Trade-off: heuristics need explicit overrides when names do not express intent.
Security as evidence, not a magic score
Dependabot, code scanning, security workflows, and OpenSSF Scorecard remain separate signals. Lack of access lowers confidence rather than becoming a security claim.
Trade-off: the result is more honest but less simplistic.
Flow
Collect, normalize, publish, and inspect without runtime coupling to GitHub.
- GitHub APIssignals distributed across sources
- Node.js collectorpagination, rules, and failure tolerance
- repositories.jsonsnapshot and read contract
- Angular SPAfilters, details, and insights
- GitHub Pagesstatic publication
- Quality gatesCI, Lighthouse, SEO, and ZAP
Trade-offs and limits
Reducing infrastructure moves complexity into the data contract and evidence interpretation.
Not real-time
The current schedule refreshes roughly every hour. That is sufficient for portfolio maintenance but does not replace production monitoring.
Not every delivery is observable
Deployments outside GitHub may not appear; versions remain blank when no trustworthy association with delivery exists.
Permissions affect coverage
Actions, Deployments, and security alerts may require additional permissions. Missing access is reported as reduced confidence.
A snapshot is not a time series
Thirty-day metrics are recomputed from the current collection window. Temporal trends require persistence of previous snapshots.
Heuristics have boundaries
Workflow names outside conventions may remain unknown. Per-repository configuration acts as an explicit override.
GitHub Pages has platform limits
Some headers and hosting behavior are not controlled by the application and must be treated as platform responsibility.
Public evidence
The case can be validated in the application, collector, and quality gates.
Published dashboardConsolidated view, details, filters, health, coverage, and confidence.
CollectorCollection, pagination, failure tolerance, and snapshot serialization.
Classification rulesHealth, workflow roles, delivery, and deterministic reasons.
AutomationCollection, tests, build, publishing, and continuous validation.
RepositoryAngular implementation, snapshot contract, security, SEO, and documentation.
Architectural reading
Engineering observability also needs to model uncertainty.
The central lesson is not “how to build a dashboard.” Consolidating engineering signals requires preserving the difference between absence, collection failure, negative evidence, and positive evidence. Without that distinction, a simple interface can produce an incorrect interpretation of the portfolio.
By making coverage and confidence explicit, Repo Control Center treats the quality of observation itself as part of the domain — reducing false diagnoses while remaining useful when not every source is available.