HOMELAB-2682: fix(forgejo-ci): a commit-status pending job is pending, not a pass #116

Merged

pi-landing merged 2 commits from plane/ci-pending-status-truth into main 2026-11-07 03:10:39 +00:00

Conversation 2 Commits 2 Files changed 4 +44 -1

pi-landing commented 2026-11-07 02:26:05 +00:00

Collaborator

Copy link

I reproduced a false claim in forgejo_ci_status, and this fixes it.

What I reproduced

Reading origin/main at aa6d009 (not a stale local main), the path is: when
actions/tasks is unhealthy and the web run page is unavailable,
resolveJobs falls back to commits/{sha}/status and builds the job list from
commit-status contexts. Commit statuses use pending for a check that has not
concluded. isPending() in forgejo-ci/forgejo.ts listed
running | waiting | queued | in_progress | blocked and not pending, so
renderStatus() saw no failing job and no pending job and chose pass.

Reproduction: one run whose status is running, actions/tasks returning the
blank 500, and two commit statuses — build-and-push: success and e2e: pending. The tool printed:

Homelab/infra-core — 1 run(s)

run #1481  c7a74c7d4a  #1665  [pass]  HOMELAB-1665: feat(agent-sandbox): pi sandbox image
    ✔ build-and-push success     1m41s
    • e2e          pending         ?
    note: jobs from commit-status contexts (actions/tasks unavailable)

[pass] on a run with an unfinished job is a false statement about CI, and the
per-job line for that job used the unknown-status icon. Both come from the same
gap: pending was not in the status vocabulary.

What changed

• forgejo-ci/forgejo.ts — isPending() now includes pending (so
  renderStatus reports running for such a run). Three comment lines say why.
• forgejo-ci/index.ts — STATUS_ICON.pending = "⏳", so the per-job line is not
  an unknown-status bullet.
• forgejo-ci/tests/tools.test.ts — new tool-level case: the scenario above must
  print run #1481 c7a74c7d4a #1665 [running], must not contain [pass], and
  must show ⏳ e2e pending.
• forgejo-ci/tests/forgejo.test.ts — new unit case pinning the vocabulary:
  isPending("pending"), isPending("PENDING") true, isPending("success")
  false, isFailed("pending") false.

Nothing else in the package consumes isPending, so the change is confined to
how a status is rendered.

Red then green

Tests were written first, against unmodified source:

• red: Test Files 2 failed | 1 passed | 1 skipped (4), Tests 2 failed | 52 passed | 11 skipped (65) — the tool-level case failed with the [pass] output
  quoted above, and expect(isPending("pending")).toBe(true) received false.
• green after the two-line fix: Test Files 3 passed | 1 skipped (4), Tests 54 passed | 11 skipped (65). forgejo-ci/tests/live.test.ts is skipped by design
  (it needs a live Forgejo session).
• npx tsc --noEmit in forgejo-ci: exit 0, no output.

What I did not measure

I did not observe a live Forgejo run in the pending commit-status state; the
case is constructed in the fake server from the documented commit-status
vocabulary. The commit-status fallback path itself is unchanged.

I reproduced a false claim in `forgejo_ci_status`, and this fixes it. ## What I reproduced Reading `origin/main` at aa6d009 (not a stale local main), the path is: when `actions/tasks` is unhealthy and the web run page is unavailable, `resolveJobs` falls back to `commits/{sha}/status` and builds the job list from commit-status contexts. Commit statuses use `pending` for a check that has not concluded. `isPending()` in `forgejo-ci/forgejo.ts` listed `running | waiting | queued | in_progress | blocked` and not `pending`, so `renderStatus()` saw no failing job and no pending job and chose `pass`. Reproduction: one run whose status is `running`, `actions/tasks` returning the blank 500, and two commit statuses — `build-and-push: success` and `e2e: pending`. The tool printed: ``` Homelab/infra-core — 1 run(s) run #1481 c7a74c7d4a #1665 [pass] HOMELAB-1665: feat(agent-sandbox): pi sandbox image ✔ build-and-push success 1m41s • e2e pending ? note: jobs from commit-status contexts (actions/tasks unavailable) ``` `[pass]` on a run with an unfinished job is a false statement about CI, and the per-job line for that job used the unknown-status icon. Both come from the same gap: `pending` was not in the status vocabulary. ## What changed - `forgejo-ci/forgejo.ts` — `isPending()` now includes `pending` (so `renderStatus` reports `running` for such a run). Three comment lines say why. - `forgejo-ci/index.ts` — `STATUS_ICON.pending = "⏳"`, so the per-job line is not an unknown-status bullet. - `forgejo-ci/tests/tools.test.ts` — new tool-level case: the scenario above must print `run #1481 c7a74c7d4a #1665 [running]`, must not contain `[pass]`, and must show `⏳ e2e pending`. - `forgejo-ci/tests/forgejo.test.ts` — new unit case pinning the vocabulary: `isPending("pending")`, `isPending("PENDING")` true, `isPending("success")` false, `isFailed("pending")` false. Nothing else in the package consumes `isPending`, so the change is confined to how a status is rendered. ## Red then green Tests were written first, against unmodified source: - red: `Test Files 2 failed | 1 passed | 1 skipped (4)`, `Tests 2 failed | 52 passed | 11 skipped (65)` — the tool-level case failed with the `[pass]` output quoted above, and `expect(isPending("pending")).toBe(true)` received `false`. - green after the two-line fix: `Test Files 3 passed | 1 skipped (4)`, `Tests 54 passed | 11 skipped (65)`. `forgejo-ci/tests/live.test.ts` is skipped by design (it needs a live Forgejo session). - `npx tsc --noEmit` in `forgejo-ci`: exit 0, no output. ## What I did not measure I did not observe a live Forgejo run in the `pending` commit-status state; the case is constructed in the fake server from the documented commit-status vocabulary. The commit-status fallback path itself is unchanged.

pi-landing added 1 commit 2026-11-07 02:26:05 +00:00

HOMELAB-2682: fix(forgejo-ci): count a commit-status pending job as pending, not a pass ... 72c18abccd

A job whose status arrives from `commits/{sha}/status` (the fallback when
actions/tasks is unhealthy) can be `pending`. isPending() did not list it, so
renderStatus() fell through to [pass] for a run with an unfinished job, and the
per-job line printed an unknown-status icon.

- isPending(): include `pending`
- STATUS_ICON: pending -> ⏳
- tests: red-then-green unit case for the vocabulary + tool-level case pinning
  that a pending commit status renders [running], never [pass]

pi-landing changed title from fix(forgejo-ci): a commit-status pending job is pending, not a pass to HOMELAB-2682: fix(forgejo-ci): a commit-status pending job is pending, not a pass 2026-11-07 02:28:59 +00:00

aaron added 1 commit 2026-11-07 02:31:56 +00:00

HOMELAB-2682: chore(forgejo-ci): retrigger CI after the PR title fix ... f5de0ed1d2

The pr-title gate ran on the title as first opened, which had no ticket prefix; it
is the only red job on the head. A fresh pull_request event re-evaluates it.

ld-reviewer commented 2026-11-07 02:51:49 +00:00

Collaborator

Copy link

Verdict of record — ld-reviewer — head f5de0ed1d2: APPROVE
model: omniroute/deepseek-flash
session: 01a1b3e6-fd99-70d7-89c1-cc264f3715c1

Blockers

None.

Measurements

Diff scope. git diff aa6d009..f5de0ed = 2 commits (72c18ab fix, f5de0ed CI retrigger) and 4 files, all inside the pending leg: forgejo-ci/forgejo.ts (isPending gains pending + 3 comment lines), forgejo-ci/index.ts (STATUS_ICON.pending = "⏳"), tests/forgejo.test.ts (vocabulary unit case), tests/tools.test.ts (tool-level case). Nothing outside the pending leg; no unrelated edit, no dependency or config change.

Before-state, reproduced by me. Local clone at base aa6d009, fake server: one run status: running, actions/tasks returning the blank 500, commits/{sha}/status = build-and-push: success + e2e: pending, no session cookie (so the web run page is unavailable). Output:

run #1481  c7a74c7d4a  #1665  [pass]  HOMELAB-1665: feat(agent-sandbox): pi sandbox image
    ✔ build-and-push success     1m41s
    • e2e          pending         ?
    note: jobs from commit-status contexts (actions/tasks unavailable)

Byte-for-byte the output quoted in the PR body. The false [pass] on a run with an unfinished job is real at main.

After-state, same scenario, head f5de0ed. Same harness, same route table:

run #1481  c7a74c7d4a  #1665  [running]  HOMELAB-1665: feat(agent-sandbox): pi sandbox image
    ✔ build-and-push success     1m41s
    ⏳ e2e          pending         ?
    note: jobs from commit-status contexts (actions/tasks unavailable)

Both halves of the complaint are fixed: the header no longer says pass, and the per-job line uses the pending icon instead of the unknown-status bullet.

Pending-leg completeness. The live Forgejo swagger (forgejo.aaron.reynoza.org/swagger.v1.json, read today) defines CommitStatusState as "pending", "success", "error", "failure", "warning" — so pending is the only unfinished commit-status spelling, and it is now listed. Actions task states that are unfinished (waiting, running, blocked) were already listed, as were the extra queued / in_progress. My spelling matrix at head, one job in each state, commit-status fallback path:

pending      -> [running]  ⏳ e2e  pending
running      -> [running]  ▶ e2e  running
waiting      -> [running]  ⏳ e2e  waiting
queued       -> [running]  ⏳ e2e  queued
in_progress  -> [running]  ▶ e2e  in_progress
blocked      -> [running]  🚧 e2e  blocked
error        -> [FAIL]     ✘ e2e  error
failure      -> [FAIL]     ✘ e2e  failure
cancelled    -> [FAIL]     ⛔ e2e  cancelled
success      -> [pass]     ✔ e2e  success
skipped      -> [pass]     ⏭ e2e  skipped
warning      -> [pass]     • e2e  warning

No unfinished spelling renders [pass] at head.

Tests, run by me at head (/tmp clone checked out at f5de0ed): Test Files 3 passed | 1 skipped (4), Tests 54 passed | 11 skipped (65); tests/live.test.ts skipped by design. npx tsc --noEmit exit 0, no output. Matches the PR body's numbers.

Red check, run by me. The PR's two new test files placed against unmodified base source, same suite: Test Files 2 failed | 1 passed | 1 skipped (4), Tests 2 failed | 52 passed | 11 skipped (65); the tool-level case failed on [pass] and the unit case on expect(isPending("pending")).toBe(true) receiving false. Exactly the claimed red.

Measured, not a blocker. A concluded warning commit status renders [pass] with the unknown-status bullet. warning is a concluded state in the same swagger enum, not an unfinished check, and it is outside this PR's pending leg — recorded here only so the next reader knows it was seen.

Exposure

I read the PR #116 metadata and full diff, forgejo-ci/forgejo.ts (isPending, isFailed, jobsFromCommitStatuses), forgejo-ci/index.ts (renderStatus, STATUS_ICON, the resolveJobs commit-status fallback), both new test cases, and the public Forgejo swagger enum. I ran, in two throwaway clones at /tmp/rv116 (base aa6d00972ad9e4d2df4e9c68f24b6d19ccf69ba9, head f5de0ed1d20b2e2206520fd3d885e52835aeb67c): my own reproduction tests against both shas, the package vitest suite at head and against base source, and npx tsc --noEmit at head. No FORGEJO_API_KEY read or used; no write other than this comment.

Verdict of record — ld-reviewer — head f5de0ed1d20b2e2206520fd3d885e52835aeb67c: APPROVE model: omniroute/deepseek-flash session: 01a1b3e6-fd99-70d7-89c1-cc264f3715c1 ## Blockers None. ## Measurements **Diff scope.** `git diff aa6d009..f5de0ed` = 2 commits (`72c18ab` fix, `f5de0ed` CI retrigger) and 4 files, all inside the pending leg: `forgejo-ci/forgejo.ts` (`isPending` gains `pending` + 3 comment lines), `forgejo-ci/index.ts` (`STATUS_ICON.pending = "⏳"`), `tests/forgejo.test.ts` (vocabulary unit case), `tests/tools.test.ts` (tool-level case). Nothing outside the pending leg; no unrelated edit, no dependency or config change. **Before-state, reproduced by me.** Local clone at base aa6d009, fake server: one run `status: running`, `actions/tasks` returning the blank 500, `commits/{sha}/status` = `build-and-push: success` + `e2e: pending`, no session cookie (so the web run page is unavailable). Output: ``` run #1481 c7a74c7d4a #1665 [pass] HOMELAB-1665: feat(agent-sandbox): pi sandbox image ✔ build-and-push success 1m41s • e2e pending ? note: jobs from commit-status contexts (actions/tasks unavailable) ``` Byte-for-byte the output quoted in the PR body. The false `[pass]` on a run with an unfinished job is real at main. **After-state, same scenario, head f5de0ed.** Same harness, same route table: ``` run #1481 c7a74c7d4a #1665 [running] HOMELAB-1665: feat(agent-sandbox): pi sandbox image ✔ build-and-push success 1m41s ⏳ e2e pending ? note: jobs from commit-status contexts (actions/tasks unavailable) ``` Both halves of the complaint are fixed: the header no longer says pass, and the per-job line uses the pending icon instead of the unknown-status bullet. **Pending-leg completeness.** The live Forgejo swagger (`forgejo.aaron.reynoza.org/swagger.v1.json`, read today) defines `CommitStatusState` as "pending", "success", "error", "failure", "warning" — so `pending` is the *only* unfinished commit-status spelling, and it is now listed. Actions task states that are unfinished (`waiting`, `running`, `blocked`) were already listed, as were the extra `queued` / `in_progress`. My spelling matrix at head, one job in each state, commit-status fallback path: ``` pending -> [running] ⏳ e2e pending running -> [running] ▶ e2e running waiting -> [running] ⏳ e2e waiting queued -> [running] ⏳ e2e queued in_progress -> [running] ▶ e2e in_progress blocked -> [running] 🚧 e2e blocked error -> [FAIL] ✘ e2e error failure -> [FAIL] ✘ e2e failure cancelled -> [FAIL] ⛔ e2e cancelled success -> [pass] ✔ e2e success skipped -> [pass] ⏭ e2e skipped warning -> [pass] • e2e warning ``` No unfinished spelling renders `[pass]` at head. **Tests, run by me at head** (`/tmp` clone checked out at f5de0ed): `Test Files 3 passed | 1 skipped (4)`, `Tests 54 passed | 11 skipped (65)`; `tests/live.test.ts` skipped by design. `npx tsc --noEmit` exit 0, no output. Matches the PR body's numbers. **Red check, run by me.** The PR's two new test files placed against unmodified base source, same suite: `Test Files 2 failed | 1 passed | 1 skipped (4)`, `Tests 2 failed | 52 passed | 11 skipped (65)`; the tool-level case failed on `[pass]` and the unit case on `expect(isPending("pending")).toBe(true)` receiving `false`. Exactly the claimed red. **Measured, not a blocker.** A concluded `warning` commit status renders `[pass]` with the unknown-status bullet. `warning` is a concluded state in the same swagger enum, not an unfinished check, and it is outside this PR's pending leg — recorded here only so the next reader knows it was seen. ## Exposure I read the PR #116 metadata and full diff, `forgejo-ci/forgejo.ts` (`isPending`, `isFailed`, `jobsFromCommitStatuses`), `forgejo-ci/index.ts` (`renderStatus`, `STATUS_ICON`, the resolveJobs commit-status fallback), both new test cases, and the public Forgejo swagger enum. I ran, in two throwaway clones at `/tmp/rv116` (base `aa6d00972ad9e4d2df4e9c68f24b6d19ccf69ba9`, head `f5de0ed1d20b2e2206520fd3d885e52835aeb67c`): my own reproduction tests against both shas, the package vitest suite at head and against base source, and `npx tsc --noEmit` at head. No `FORGEJO_API_KEY` read or used; no write other than this comment.

ld-reviewer commented 2026-11-07 03:04:44 +00:00

Collaborator

Copy link

Verdict of record — ld-reviewer — head f5de0ed1d2: APPROVE

model: omniroute/deepseek-flash
session: 01a1b3ef-7e5e-70d7-89c1-cc2d6a74a33a

Blockers

None.

What I measured (independently; seat-2 worktrees, own probe file)

1. Diff scope. git diff aa6d0097 f5de0ed1 = 2 commits, 4 files, +44/−1: forgejo.ts (isPending() gains pending + 3 comment lines), index.ts (STATUS_ICON.pending = "⏳"), the two test files. Nothing beyond the pending leg. f5de0ed alone is an empty CI-retrigger commit.

2. Before/after on the claimed scenario. Own probe (tests/s2probe.test.ts, mine, deleted after), run status: "running", actions/tasks → blank500(), commit statuses build-and-push: success / e2e: pending:

• base aa6d0097: run #1481 c7a74c7d4a #1665 [pass] and • e2e pending ?
• head f5de0ed1: run #1481 c7a74c7d4a #1665 [running] and ⏳ e2e pending ?
  The false pass is real on base and gone on head.

3. Completeness of the pending leg (both spellings sets, read at source):

• Commit statuses: forgejo 14.0.3 (live /api/v1/version = 14.0.3+gitea-1.22.0), services/actions/commit_status.go toCommitStatus() maps waiting|blocked|running → pending, success|skipped → success, failure|cancelled → failure, default → error. So pending is the only unfinished spelling Forgejo's actions writer ever emits here — it was the whole gap on this leg, and it is now covered. CommitStatusState swagger doc agrees (pending|success|error|failure|warning).
• Actions job states (models/actions/status.go: unknown|waiting|running|success|failure|cancelled|skipped|blocked), fed by actions/tasks and by the run page (ViewJob.Status = job.Status.String(), routers/web/repo/actions/view.go). Unfinished = waiting, running, blocked; all three were already in isPending() and I re-verified each renders [running] in all three sources (tasks, run-page, commit-status).
• unknown is Forgejo's zero value and is not reachable on either feeding path: models/actions/run.go inserts every run job with StatusBlocked | StatusWaiting | StatusFailure only (nil/unparseable job payload), and toCommitStatus sends unknown to error (renders [FAIL], never pass). So no unfinished, actually-emitted spelling still renders pass. Observation only (not a blocker): isPending() still omits unknown, which actions.PendingStatuses() does list — a defensive addition if you want belt-and-braces, unreachable today.

4. Behaviour beyond pending. My probe sweeps 21 scenarios (10 commit-status spellings, 6 task spellings, 5 run-page spellings) on base and head; diff of the two outputs changes exactly 4 rows — CS pending, CS PENDING, TASKS pending, PAGE pending — header [pass] → [running] plus icon • → ⏳. No other state's header or icon changed, no ordering change, error → [FAIL], warning|skipped → [pass] unchanged on both sides. Grep confirms isPending has exactly one consumer (index.ts:265, renderStatus), so the PR's "nothing else consumes isPending" holds. STATUS_ICON is read only by icon() (no legend iteration), so the new entry cannot affect other states.

5. Tests at head (worktree of f5de0ed1, package node_modules symlinked): npx vitest run → Test Files 3 passed | 1 skipped (4), Tests 54 passed | 11 skipped (65); same suite on base → 52 passed | 11 skipped (63) (delta = the 2 new tests). npx tsc --noEmit → exit 0, no output.

6. CI on the head (read via forgejo_ci_status, filter #116): run #406 on f5de0ed1d2, all 15 jobs success, run header [pass].

Exposure

Read: local git objects base aa6d00972ad9e4d2df4e9c68f24b6d19ccf69ba9 and head f5de0ed1d20b2e2206520fd3d885e52835aeb67c (diff, both test files, forgejo-ci/{forgejo,index,types}.ts), forgejo 14.0.3 source at tag v14.0.3 (models/actions/status.go, models/actions/run.go, routers/web/repo/actions/view.go, services/actions/commit_status.go), the instance swagger (CommitStatusState), live /api/v1/version. Ran: my own tests/s2probe.test.ts in two detached worktrees (/tmp/s2-116/base, /tmp/s2-116/head), the package suite and tsc --noEmit in both, forgejo_ci_status for PR #116. I did not modify the PR branch, did not run a live pending run, and posted nothing but this verdict.

Verdict of record — ld-reviewer — head f5de0ed1d20b2e2206520fd3d885e52835aeb67c: APPROVE model: omniroute/deepseek-flash session: 01a1b3ef-7e5e-70d7-89c1-cc2d6a74a33a ## Blockers None. ## What I measured (independently; seat-2 worktrees, own probe file) **1. Diff scope.** `git diff aa6d0097 f5de0ed1` = 2 commits, 4 files, +44/−1: `forgejo.ts` (`isPending()` gains `pending` + 3 comment lines), `index.ts` (`STATUS_ICON.pending = "⏳"`), the two test files. Nothing beyond the pending leg. `f5de0ed` alone is an empty CI-retrigger commit. **2. Before/after on the claimed scenario.** Own probe (`tests/s2probe.test.ts`, mine, deleted after), run `status: "running"`, `actions/tasks` → `blank500()`, commit statuses `build-and-push: success` / `e2e: pending`: - base aa6d0097: `run #1481 c7a74c7d4a #1665 [pass]` and ` • e2e pending ?` - head f5de0ed1: `run #1481 c7a74c7d4a #1665 [running]` and ` ⏳ e2e pending ?` The false pass is real on base and gone on head. **3. Completeness of the pending leg** (both spellings sets, read at source): - *Commit statuses*: forgejo 14.0.3 (live `/api/v1/version` = `14.0.3+gitea-1.22.0`), `services/actions/commit_status.go` `toCommitStatus()` maps `waiting|blocked|running → pending`, `success|skipped → success`, `failure|cancelled → failure`, `default → error`. So `pending` is the **only** unfinished spelling Forgejo's actions writer ever emits here — it was the whole gap on this leg, and it is now covered. `CommitStatusState` swagger doc agrees (`pending|success|error|failure|warning`). - *Actions job states* (`models/actions/status.go`: `unknown|waiting|running|success|failure|cancelled|skipped|blocked`), fed by `actions/tasks` and by the run page (`ViewJob.Status = job.Status.String()`, `routers/web/repo/actions/view.go`). Unfinished = `waiting`, `running`, `blocked`; all three were already in `isPending()` and I re-verified each renders `[running]` in all three sources (`tasks`, `run-page`, `commit-status`). - `unknown` is Forgejo's zero value and is **not reachable** on either feeding path: `models/actions/run.go` inserts every run job with `StatusBlocked | StatusWaiting | StatusFailure` only (nil/unparseable job payload), and `toCommitStatus` sends `unknown` to `error` (renders `[FAIL]`, never `pass`). So no unfinished, actually-emitted spelling still renders pass. Observation only (not a blocker): `isPending()` still omits `unknown`, which `actions.PendingStatuses()` does list — a defensive addition if you want belt-and-braces, unreachable today. **4. Behaviour beyond pending.** My probe sweeps 21 scenarios (10 commit-status spellings, 6 task spellings, 5 run-page spellings) on base and head; `diff` of the two outputs changes exactly 4 rows — `CS pending`, `CS PENDING`, `TASKS pending`, `PAGE pending` — header `[pass] → [running]` plus icon `• → ⏳`. No other state's header or icon changed, no ordering change, `error → [FAIL]`, `warning|skipped → [pass]` unchanged on both sides. Grep confirms `isPending` has exactly one consumer (`index.ts:265`, `renderStatus`), so the PR's "nothing else consumes isPending" holds. `STATUS_ICON` is read only by `icon()` (no legend iteration), so the new entry cannot affect other states. **5. Tests at head** (worktree of f5de0ed1, package `node_modules` symlinked): `npx vitest run` → `Test Files 3 passed | 1 skipped (4)`, `Tests 54 passed | 11 skipped (65)`; same suite on base → `52 passed | 11 skipped (63)` (delta = the 2 new tests). `npx tsc --noEmit` → exit 0, no output. **6. CI on the head** (read via `forgejo_ci_status`, filter `#116`): run #406 on `f5de0ed1d2`, all 15 jobs `success`, run header `[pass]`. ## Exposure Read: local git objects base `aa6d00972ad9e4d2df4e9c68f24b6d19ccf69ba9` and head `f5de0ed1d20b2e2206520fd3d885e52835aeb67c` (diff, both test files, `forgejo-ci/{forgejo,index,types}.ts`), forgejo 14.0.3 source at tag `v14.0.3` (`models/actions/status.go`, `models/actions/run.go`, `routers/web/repo/actions/view.go`, `services/actions/commit_status.go`), the instance swagger (`CommitStatusState`), live `/api/v1/version`. Ran: my own `tests/s2probe.test.ts` in two detached worktrees (`/tmp/s2-116/base`, `/tmp/s2-116/head`), the package suite and `tsc --noEmit` in both, `forgejo_ci_status` for PR #116. I did not modify the PR branch, did not run a live pending run, and posted nothing but this verdict.

pi-landing merged commit 55518b3504 into main 2026-11-07 03:10:39 +00:00

pi-landing referenced this pull request from a commit 2026-11-07 03:10:40 +00:00

Merge pull request 'HOMELAB-2682: fix(forgejo-ci): a commit-status pending job is pending, not a pass' (#116) from plane/ci-pending-status-truth into main

ld-reviewer referenced this pull request 2026-11-07 03:25:41 +00:00

HOMELAB-2682: feat(forgejo-ci): read FORGEJO_API_KEY_FILE first (scoped) #117

ld-reviewer referenced this pull request 2026-11-07 04:47:06 +00:00

HOMELAB-2682: feat(forgejo-ci): read FORGEJO_API_KEY_FILE first (scoped) #117

ld-reviewer referenced this pull request 2026-11-07 04:49:20 +00:00

HOMELAB-2682: feat(forgejo-ci): read FORGEJO_API_KEY_FILE first (scoped) #117

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

3 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

Homelab/pi-extensions!116

No description provided.