Check weekly checks forgejo actions #18
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Yilan should with each run look at the status of the last weekly check forgejo action run and show a tick against the project if the weekly check finished successfully or a cross if the the weekly run ended with a non zero return code.
Additionally it might be nice to re-order the table in the top of BOARD.md so that projects where the last weekly checks run was unsuccessful are at the top.
Documenting the design discussion for this issue.
What the feature needs
Per-repo ✓/✗ for the
weekly-checks.ymlForgejo Actions workflow, with failures sorted to the top of the summary table.Findings (verified against the live API)
Use
/actions/tasks, not/actions/runs. Two endpoints, different shapes:/actions/runs— sparse:conclusionnull,created_atnull,eventmisreported aspush./actions/tasks— GitHub-compatible: hascreated_at,run_number,head_sha, correctevent: "schedule".Timestamps exist and
event == "schedule"works; use/actions/tasks.Terminal state is
status, notconclusion. Values:success/failure/cancelled. "Non-zero return code" →status == "failure". Decide: iscancelleda ✗ or a separate ⚠? What does a still-running run (in_progress/queued) show at scrape time?Per-job granularity.
nameis the job name; one entry per job per run (multi-job workflows split, sharingrun_number). Scope byworkflow_id(the filename).weekly-checks.ymlis single-job today; a trap if it ever grows a second job.No server-side filtering.
?event=schedulewas ignored (still returned push/release/PR rows). Filter client-side onevent == "schedule"+workflow_id == "weekly-checks.yml", newest-first. Busy repos may need pagination to reach the last schedule run.Third state: "never run yet". Post-migration, most repos have the workflow but zero runs yet. Needs distinct rendering and a sort decision ("not yet run" is not a failure). Distinguish it from "no workflow at all" — an empty runs list is ambiguous; either rely on "every repo has weekly-checks.yml" (empty == never ran) or probe the raw workflow file (200/404).
Staleness is a feature decision now.
created_atexists, so yilan can render "last ran YYYY-MM-DD" and flag green-but-older-than-N-days. Decide the decay policy.SHA cache must be bypassed. Weekly-check status changes without a commit (scheduled run on same HEAD, manual re-run, first run). The commit-SHA cache would freeze it; fetch actions separately (always, or its own TTL).
Discovery prerequisite: exclude private repos. The checks column inherits yilan's repo list, and
_fetch_owner_reposcurrently filters onlyfork+archived— noprivatefilter.BOARD.mdis public, so a private repo (e.g. arvak) would leak issues/TODO/commits. Token choice interacts: anonymous scrape auto-drops private repos but is rate-limited; a broad PAT sees them and must filterprivate == trueexplicitly.Sort interaction. Current sort is active-first, then name. "Failed weekly check" becomes the top key — decide precedence (failed vs active), the tiebreak for multiple failures, and whether reordering the table also reorders the
###prose sections (they share the samereposlist).Plumbing. New
RepoDatafield, a summary-table column, a- **Weekly check**:prose line, andRepoDiff/snapshot tracking soyilan diffreports ✓→✗ transitions.Finalized plan (board-automation design):
Closed via commit
84a7cbf: yilan now fetches weekly-check status from the Forgejo Actions API, displays a ✓/✗/— column in BOARD.md, and sorts repos with failed weekly checks to the top.