Skip to content

feat: add gitea actions support#4

Open
xbuzz wants to merge 1 commit into
mainfrom
feat/gitea-support
Open

feat: add gitea actions support#4
xbuzz wants to merge 1 commit into
mainfrom
feat/gitea-support

Conversation

@xbuzz
Copy link
Copy Markdown
Owner

@xbuzz xbuzz commented May 8, 2026

Summary

  • bong now watches gitea actions runs in addition to gitlab pipelines
  • provider is auto-detected from URL shape (/-/pipelines/ → gitlab, /actions/runs/ → gitea) and from the origin remote host (gitlab* / codeberg.org / *gitea*); BONG_PROVIDER=gitlab|gitea is the explicit override
  • gitea path is curl + GITEA_HOST (auto-derived from remote) + optional GITEA_TOKEN — keeps the zero-deps-beyond-glab ethos for gitlab users and adds nothing but curl (already there) for gitea users
  • gitlab path is byte-identical: same glab api calls, same downstream chasing, same manual-gate notifications

Design notes

  • Thin dispatch layer over fetch_repo_id / fetch_latest_json / fetch_run_json keeps the main loop provider-agnostic. The two gitlab-specific behaviors (downstream discovery via bridges, manual-gate detection) are gated on $PROVIDER == gitlab. Gitea Actions has no equivalent of either concept, so on gitea we watch the single run.
  • Status normalization: gitea's vocabulary (failure/cancelled/in_progress/waiting/queued) is mapped to gitlab's (failed/canceled/running/pending) at JSON-read time. The state machine downstream of that is unchanged.
  • Repo identifier: numeric project id for gitlab, "owner/repo" string for gitea — both stash into the same PROJS array since each invocation only watches one provider.
  • Host derivation: GITEA_HOST env wins; otherwise we sniff scheme+host from git remote get-url origin (handles both git@host:path and https://host/path forms). When the user supplies a gitea URL, the host from the URL becomes GITEA_HOST if env is unset.

Test plan

  • bash -n bong (syntax)
  • bong --help shows updated text
  • 27-case helper test suite (provider detection, JSON extraction, status normalization, host derivation, repo resolution) — all green; suite included in PR description below for repro
  • manual: bong https://gitlab.com/foo/bar/-/pipelines/N against a real gitlab pipeline (regression — gitlab path is unchanged but should be eyeballed)
  • manual: bong https://codeberg.org/owner/repo/actions/runs/N against a real public gitea run (no token)
  • manual: bong N from inside a gitea-remote repo with GITEA_TOKEN set
  • manual: BONG_PROVIDER=gitea bong N overrides auto-detection
Helper test suite (paste into a tmp file, run with bash)
sed -n '/^# bong/,/^main "\$@"$/p' bong | sed '$d' > /tmp/bong_lib.sh
unset BONG_PROVIDER; PROVIDER=
. /tmp/bong_lib.sh

fail=0
expect() { [[ $1 == "$2" ]] && echo "ok   $3" || { echo "FAIL $3 — got $1 want $2"; fail=1; }; }

PROVIDER=
expect "$(detect_provider 'https://gitlab.com/x/y/-/pipelines/1')"  gitlab "gitlab url"
expect "$(detect_provider 'https://codeberg.org/x/y/actions/runs/1')" gitea "gitea url"
PROVIDER=gitea
expect "$(detect_provider '12')" gitea "BONG_PROVIDER override"
PROVIDER=gitlab
expect "$(detect_provider 'https://codeberg.org/x/y/actions/runs/1')" gitlab "override beats url"

PROVIDER=gitea
expect "$(read_status '{"status":"failure"}')"     failed   "failure→failed"
expect "$(read_status '{"status":"cancelled"}')"   canceled "cancelled→canceled"
expect "$(read_status '{"status":"in_progress"}')" running  "in_progress→running"
expect "$(read_status '{"status":"waiting"}')"     pending  "waiting→pending"

exit $fail

bong now auto-detects the provider from the URL shape (`/-/pipelines/` →
gitlab, `/actions/runs/` → gitea) or from the `origin` remote host, with
`BONG_PROVIDER` as an explicit override.

Implementation:
- thin dispatch layer over fetch_repo_id / fetch_latest_json / fetch_run_json
- gitlab path is unchanged (still glab api)
- gitea path is curl + GITEA_HOST (auto from remote) + optional GITEA_TOKEN
- gitea statuses (failure/cancelled/in_progress/waiting/queued) are
  normalized to gitlab vocabulary so the main loop stays provider-agnostic
- discover_children + manual-gate handling are no-ops on gitea (Actions has
  neither concept)
- gitea project id is the "owner/repo" string (vs numeric for gitlab),
  stashed into the same PROJS array
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant