search

sailfishos-chum / sailfishos-chum-gui

GUI application for utilising the SailfishOS:Chum community repository
https://openrepos.net/content/olf/sailfishoschum-gui-installer
MIT License
13 stars 16 forks source link

Add support for Forgejo/Gitea remote repos #271

Closed nephros closed 1 month ago

nephros commented 2 months ago

This adds support for remote SCM hosts running gitea or forgejo software, similar to the gitlab and github integration we already have (except this is not using GraphQL).

Tested only with codeberg.org (forgejo), and by running curl against https://try.gitea.io.

API docs can be accessed by browsing to <instance host>/api/swagger for both gitea and forgejo, e.g:

A new API key will have to be generated for at least codeberg.org so Github can use it in the build Action. The format of the TOKEN_FORGEJO for github actions follows that of the Gitlab implementation:

"gitea.example.com:XXXX|forgejo.example.com:YYYY|...|siteN:tokenN"

Quoting being essential here! (The github workflow breaks otherwise because of pipes in a shell script!)

s.a. https://github.com/sailfishos-chum/sailfishos-chum-gui/pull/44

nephros commented 2 months ago

How to create an api token (on codeberg):

  1. Go to https://codeberg.org/user/settings/applications
  2. Select "Generate new Token"
  3. Give it a name, e.g. "chum-gui-read"
  4. From the Options: "Public Only"
  5. Expand "permissions"
  6. Set "issue" -> "read"
  7. Set "repository" -> "read"
  8. Click "Generate Token"
nephros commented 2 months ago

This adds support for remote SCM hosts running gitea or forgejo software, similar to the gitlab and github integration we already have (except this is not using GraphQL).

On side-effect of the API differences is that with the HTTP API I can't fetch issue details and issue comments in one go like GraphQL can.

For now I have implemented that a bit clunkily by first filling the issue details, and then fetching comments and adding them:

https://github.com/nephros/sailfishos-chum-gui/blob/550c5b2f9db6152b0d2b48f5625f603b5444d5b6/src/projectforgejo.cpp#L196

https://github.com/nephros/sailfishos-chum-gui/blob/550c5b2f9db6152b0d2b48f5625f603b5444d5b6/src/projectforgejo.cpp#L132

This probably has issues with async callbacks but it works AFAICS. Please review and suggest improvement.

One solution I can see is to split the issue list and issue comments into separate models, but that would mean rework of the gitlab and github implementations.

Olf0 commented 2 months ago

Thank you very much for this addition.

I have to admit that it took me a bit of research to fully understand, why you treated forgejo and gitea as one: Forgejo (source code) is a fork of Gitea (source code, add-ons) in December 2022, which in turn is a fork of Gogs (source code) in November 2016.

All three are written in Go, and forgejo and gitea obviously still share the same token (i.e. "API key") format and APIs.

@nephros, is there a specific reason why you did not mention Gogs? E.g. does it not still share the same token format and APIs? Or was it just due to not being aware of the common, original basis these three git-based web-frontends share? As you can see Gogs' SCM, it is still under development (albeit slowly).

We also should document that forgejo and gitea currently means the same with regard to token format and APIs as used by the SailfishOS:Chum GUI app. But that sure does not have to be addressed by this PR. Currently I even lack an idea where to document this best; I will try to think about it and look at extant documentation to find an appropriate place during the next weekend.

Tested only with codeberg.org (forgejo), and by running curl against https://try.gitea.io/.

I think that is fine, because codeberg.org is more or less forgejo's public reference server.

For Gogs you may try running curl against try.gogs.io (uses a valid x.509 certificate for a different domain: It might require to use curl -k (= --insecure), or to download the certificate chain in PEM format in a browser and use curl --cacert <foo>.pem), or try one of the methods (local installation or running a container) from the section "Easy to install" (the "Install Now" button resolves to docs/installation, which primarily describes the requirements for a local installation).

Unfortunately, there does not seem to be a proper API documentation on the web (this is the best I found), but maybe something is accessible on a running instance (as with forgejo and gitea).

P.S.: WRT code review I kindly ask @piggz and/or @rinigus, if one or both of you can spare the time; but actually one should first review and react to the latest comments for the much older PR #266, because it has been stalled since December 2023.

nephros commented 2 months ago

I indeed wasn't aware of gogs.

I found API docs here:

https://github.com/gogs/docs-api

Haven't looked into it, but I'll to a test sometime later. Could be it just works.

The thing with all the self-hosted things is that they're hard to detect. Right now we just 'brute-force' try to access the URL/Repo/PackagingRepo metadata urls (all three, in that order). The first that doesn't error out is picked.
Not terrible, but not very elegant either.

nephros commented 2 months ago

Haven't looked into it, but I'll to a test sometime later. Could be it just works.

Scratch that, try.gogs.io is not working ATM. I might revisit but that is lowest possible prio as I don't think anyone in the SFOS/chum world is likely to use it.

Olf0 commented 2 months ago

I found API docs here: https://github.com/gogs/docs-api

Cool, I somehow missed this.

Could be it just works.

IMO basically the whole Gogs story is only for these cases: "Just works" or "works with minimal adaptions". Any other case would put it outside of having a common denominator with Forgejo and Gitea, any way.

The thing with all the self-hosted things is …

IMO that is fine; how else would one address that easily?

Scratch that, try.gogs.io is not working ATM.

As stated (I later expanded that statement to clarify it):

For Gogs you may try running curl against try.gogs.io (uses a valid x.509 certificate for a different domain: It might require to use curl -k (= --insecure), or to download the certificate chain in PEM format in a browser and use curl --cacert <foo>.pem), or try one of the methods (local installation or running a container) from the section "Easy to install".

nephros commented 2 months ago

As stated (I later expanded that statement to clarify it):

For Gogs you may try running curl against try.gogs.io (uses a valid x.509 certificate for a different domain: It might require to use curl -k (= --insecure), or to download the certificate chain in PEM format in a browser and use curl --cacert <foo>.pem), or try one of the methods (local installation or running a container) from the section "Easy to install".

That's the first issue. The second one is that the server literally sends nothing once you force-ignore the certificate problem. (And a quick googling indicates that is possibly a Docker misconfiguration - so maybe the admins of that site should read that guide! :D )

And nope I will not set up a containered instance of a rather fringe service to test three api calls to have the number of "stars" displayed in (maybe!) one or so Chum packages (no offense!). And as this seems to be self-hosted only with no widely-used public service we can't create API tokens anyway.

Still, thanks for your research and pointers!

Olf0 commented 2 months ago

I was just about to walk through your nice step-by-step guide how to create a token for Forgejo / Gitea using codeberg.org, but GitHub does not allow to look at extant tokens (just to overwrite them with new content), so I went through the code again to determine the format used by the SailfishOS:Chum-GUI app … only to see later that you and rinigus documented this nicely: I would have missed the quoting.

Side note: This made me realise that the whole scheme is not well maintainable, when multiple GitLab or Forgejo / Gitea instances are accessed. Either one saves the "secret" (well not so much here) tokens offline (hardly feasible with multiple maintainers), or one retrieves them by strings, or one recreates all tokens for the GitLab or Forgejo / Gitea instances anew each time an instance is added or deleted, because GitHub does not allow to alter (i.e. here: extend or shorten) an extant token string (only allows for overwriting it). The third way is also not really feasible, because one does not know how many and which instances are already in a token string, when intending to add a new one; this leaves a single, awkward method as viable. Edit: … which failed for me (though that may have been an error on my side), but they are also available at the SailfishOS-OBS, where they need to be filed without quoting (in contrast to the GH-secrets for the GH-CI workflows).

TL;DR

A secret TOKEN_FORGEJO with the content "codeberg.org:<token>" is now set, created according to your excellent guidance.

Olf0 commented 1 month ago

Fine, I think we are all set; as my call for a proper code review (which I cannot provide) by the other co-maintainers was unsuccessful, do you @nephros want to look over it again, before I merge this PR?

nephros commented 1 month ago

I've been running a build of this for a bit, it appears to be working as it should.

So go ahead, if something breaks I'll pick up any pieces I find.