Replies: 4 comments
-
|
Hello @7h3-3mp7y-m4n, please take a look of the above plan as discussed earlier and let me know if I missed anything or for any mistakes. |
Beta Was this translation helpful? Give feedback.
-
|
Hey @cmainas :) Just wanted to share a quick update on my progress so far. I started by reading the documentation for the GitHub API and began experimenting with it. To get some hands-on experience, I built a small (very minimal) prototype, kind of a beginner-level dashboard, that fetches GitHub Actions workflow data for urunc. You can check the prototype here: Dashboard: https://7h3-3mp7y-m4n.github.io/GitHub-api-learner/Repo: https://github.com/7h3-3mp7y-m4n/GitHub-api-learnerThe UI is very bad at the moment (not good at it)... I also started looking at the urunc CI workflows and noticed that some workflow data might not be relevant for the dashboard, such as At the moment, I’m continuing to explore the CI workflows in the urunc repository. Alongside that, I’m also looking into possible storage options for the collected data and thinking about additional things that could be useful to include in the dashboard. Also, if there are specific areas where you think I should focus more attention, that would be really helpful. Looking forward to the upcoming meeting! :) |
Beta Was this translation helpful? Give feedback.
-
[WIP] Phase 1 Report1. Problem Statementurunc is an open source container runtime that integrates unikernels into cloud-native environments. Like any actively maintained open source project, it depends on a CI pipeline to validate that incoming contributions, whether bug fixes, new features, or configuration changes, do not break existing functionality. urunc's CI pipeline is powered by GitHub Actions, which handles building, testing, linting, and integration validation on every contribution. However, when it comes to monitoring and observability, maintainers currently have nothing beyond the default GitHub Actions tab. The GitHub Actions tab does offer basic filtering options; runs can be filtered by event, status, branch, and actor. While these filters help narrow down a list of runs, they are essentially just a better way to search through the same flat, chronological list. A maintainer can filter to see only failed runs on the main branch, but still has to manually click into each one individually to understand what broke, which job failed, and whether it is part of a larger pattern. The tab is a log viewer, not an observability tool. In day-to-day practice, this creates real, compounding problems:
These are not minor inconveniences. As urunc grows and the pace of contributions increases, the cost of missing a regression, overlooking a flaky test, or failing to notice a gradual slowdown in the pipeline becomes significantly higher. A CI system that nobody can effectively monitor is only doing half its job. What urunc needs is a dedicated CI observability system — one that automatically collects data from GitHub Actions, stores it over time, and presents it in a centralized dashboard. This would give maintainers immediate, organized visibility into CI health, failure trends, and performance anomalies without having to manually inspect individual runs. The goal is not to replace GitHub Actions, but to fill the observability gap that it leaves behind. 2. Theoretical Background2.1 GitHub Actions APIGitHub provides two APIs for interacting with repository data — a REST API and a GraphQL API. For building a CI observability system, the REST API is the only viable option as it is the only one that exposes GitHub Actions workflow data such as runs, jobs, steps, and timing REST API is the foundation of this observability system. It exposes CI data at three levels:
curl -H "Authorization: Bearer {YOUR_TOKEN}" \
-H "Accept: application/vnd.github+json" \
https://api.github.com/repos/urunc-dev/urunc/actions/runsGraphQL API allows fetching only specific fields which sounds ideal, however it does not support GitHub Actions workflow data — runs, jobs, steps and timing are simply not available through GraphQL. Therefore the REST API is the only viable option for this project. Rate Limits are an important practical consideration:
For urunc a Personal Access Token is sufficient given its current scale. 2.2 CI Data ModelThe GitHub Actions REST API exposes CI data at three levels that connect to each other:
Some of the fields most relevant for observability are:
2.3 Collecting, Filtering and Aggregating DataSince urunc has multiple workflows running independently, the observability system needs to collect data from all of them, filter it to what is meaningful, and aggregate it into useful metrics. Collection — Two approaches are possible:
The Scheduled GitHub Action is recommended because it stores historical data, keeps the token safely server side — which is important for GitHub Pages deployment — and produces pre-aggregated data that makes the dashboard fast. Filtering — Since the dashboard targets a single branch (main), filters are designed to improve signal quality and speed up debugging:
Aggregation computed metrics saved as JSON for the dashboard
3. Storage OptionsThe collector script saves processed data that the dashboard reads. The storage solution must be simple, free or low cost, and compatible with GitHub Pages or others.
4. Notification OptionsWhen CI health degrades — repeated failures on main, a flaky job appearing, or a new regression, maintainers need to be notified without having to manually check GitHub
5. Dashboard design5.1 What the Dashboard Must ShowBased on the CI structure of urunc and the data available from the GitHub Actions API, when we open the dashboard, we should be able to immediately answer:
We can utilize more information from the GitHub API for processing more important data for the dashboard 5.2 System ArchitectureThe urunc CI dashboard follows the ETL (Extract, Transform, Load) pattern combined with Static Site Generation. The key difference from a simpler approach, such as having the dashboard call the GitHub API directly, is that all computation happens at collection time rather than display time. The dashboard never touches the API, never needs a token, and never performs any aggregation. It simply reads a pre-processed file and renders it. |
Beta Was this translation helpful? Give feedback.
-
|
Hello @7h3-3mp7y-m4n , a small recap of the latest sync (30/03).
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Mentorship plan: Dashboard and Notification System for CI Testing
This discussion outlines the proposed plan as discussed with @7h3-3mp7y-m4n for the CNCF mentorship project "Dashboard and notification system for CI testing" for
urunc.The plan is structured into three phases. Each phase has clear goals and specific outcomes, along with suggested tasks and sub-tasks to help guide the work. The listed sub-tasks are meant as guidance and reference points, they are not strict requirements. The exact order of tasks within each phase can be adjusted as long as the main outcomes are achieved.
Phase 1
The goal of Phase 1 is to build the necessary background and context for designing and implementing the dashboard and notification system. This phase is expected to last up to 3 weeks (02/03/2026 – 22/03/2026). During this time, the focus will be on understanding the current CI setup, the relevant parts of urunc, and clarifying requirements that will influence the design decisions in the next phases.
Tentative tasks and sub-tasks
Outcome
Deadline: Completed no later than 22/03/2026 (AoE).
Description: A report with:
Phase 2
The goal of Phase 2 is to build a working version of the dashboard and notification system. This phase is expected to last up to 5 weeks (23/03/2026 – 03/05/2026). During this period, the focus will shift to the actual implementation of the system, including integrating the necessary components and bringing the system to a functional state.
Tentative tasks and sub-tasks
Outcome
Deadline: Completed no later than 02/05/2026 (AoE).
Description: A first version of the CI dashboard with the basic functionalities.
Phase 3
The goal of Phase 3 is to polish and finalize the dashboard and notification system and expand it with some initial performance testing. This phase is expected to last up to 4 weeks (04/05/2026 – 28/05/2026). During this period, the focus will be on finalizing and refining the whole system and adding an initial support and integration of performance testing.
Tentative tasks and sub-tasks
Outcome
Deadline: Completed no later than 29/05/2026 (AoE).
Description: The following items:
Beta Was this translation helpful? Give feedback.
All reactions