Apache NiFi Registry is being removed in NiFi 3.0, and NiFi 2 already supports Git-based Flow Registry Clients (currently GitHub, GitLab, Bitbucket, Azure DevOps officially). I wanted a self-hosted backend, so I tried pointing NiFi’s GitHubFlowRegistryClient at a Gitea instance, relying on Gitea’s GitHub API compatibility.
It mostly worked — repository access, tokens, authentication all checked out — until branch listing consistently failed with “no read access”, even though GET /repos/{owner}/{repo} clearly returned full read/write/admin permissions.
Root cause: the /collaborators/{username}/permission endpoint. GitHub’s version only ever returns admin, write, read, or none. Gitea returns "owner" for the repository owner — a distinct role above admin in Gitea’s permission model (only the owner can transfer/delete a repo). NiFi’s GitHub client has no case for that value and silently treats it as no access.
Rather than patch Gitea to remap that one string (and carry a fork across every future upgrade), I wrote a native Flow Registry Client against Gitea’s real API instead — same AbstractFlowRegistryClient SPI the GitHub/GitLab/Bitbucket clients use, but with access validation based on the boolean permissions.pull/push/admin fields from the repo endpoint, skipping the incompatible collaborators/permission check entirely.
Tested on NiFi 2.11: flow creation, versioning, pushing new snapshots, and restoring previous versions all work end to end.
Full writeup with the debugging process (including the curl output that exposed the "owner" vs admin/write/read/none mismatch): [link all’articolo LinkedIn]
Curious whether this is a known gap for anyone else who’s tried wiring GitHub-compatible clients against Gitea, or if there’s appetite for upstreaming a native Gitea client into apache/nifi directly.