feat: add gitea actions support#4
Open
xbuzz wants to merge 1 commit into
Open
Conversation
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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
/-/pipelines/→ gitlab,/actions/runs/→ gitea) and from theoriginremote host (gitlab*/codeberg.org/*gitea*);BONG_PROVIDER=gitlab|giteais the explicit overridecurl+GITEA_HOST(auto-derived from remote) + optionalGITEA_TOKEN— keeps the zero-deps-beyond-glabethos for gitlab users and adds nothing butcurl(already there) for gitea usersglab apicalls, same downstream chasing, same manual-gate notificationsDesign notes
fetch_repo_id/fetch_latest_json/fetch_run_jsonkeeps the main loop provider-agnostic. The two gitlab-specific behaviors (downstream discovery viabridges, manual-gate detection) are gated on$PROVIDER == gitlab. Gitea Actions has no equivalent of either concept, so on gitea we watch the single run.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."owner/repo"string for gitea — both stash into the samePROJSarray since each invocation only watches one provider.GITEA_HOSTenv wins; otherwise we sniff scheme+host fromgit remote get-url origin(handles bothgit@host:pathandhttps://host/pathforms). When the user supplies a gitea URL, the host from the URL becomesGITEA_HOSTif env is unset.Test plan
bash -n bong(syntax)bong --helpshows updated textbong https://gitlab.com/foo/bar/-/pipelines/Nagainst a real gitlab pipeline (regression — gitlab path is unchanged but should be eyeballed)bong https://codeberg.org/owner/repo/actions/runs/Nagainst a real public gitea run (no token)bong Nfrom inside a gitea-remote repo withGITEA_TOKENsetBONG_PROVIDER=gitea bong Noverrides auto-detectionHelper test suite (paste into a tmp file, run with bash)