Add support for Forgejo backend

[philiprenich]

For context and discussion, with a potential solution, see #198

With Foregjo now being a hard fork of Gitea, a separate change is needed in their codebase for this to be supported.The Gitea patch from the above linked issue should hopefully be portable to Forgejo to expedite this, if someone has the time and knowledge to do that.

This issue is a way to track if that work happens so support here can happen once it does. And as a way to point someone to a place to contribute if they're able.

There's no expectation for work to be done in Sveltia prior to Forgejo's API supporting the needs and issues laid out in #198.

[philiprenich]

Gitea now has the correct API to be supported by this project. Hopefully it can be used as a template for Forgejo to be supported.

[oliverpool]

Upstream issue: https://codeberg.org/forgejo/forgejo/issues/8079

(since Sveltia can't do anything before Forgejo is updated)

[kyoshino]

Great! I’ve updated the Sveltia README to change the status of Forgejo support from “Features not to be implemented” to “Current limitations.” Sveltia can identify Forgejo by its version number and adjust the behaviour if the API differs.

sveltia-cms/src/lib/services/backends/gitea.js

Lines 270 to 271 in 74cdaa1

	// Check if it’s Forgejo. The `version` will look like `11.0.1-46-17b3302+gitea-1.22.0`
	if (version.includes('+gitea-')) {

[kyoshino]

GET is the right REST API method in this case, but file paths could be very long if nested collections are used. So it might be safer to use POST just like Gitea. There is a similar Decap issue, and I’m wondering how to work around it in our GitHub backend:

• GitHub GraphQL API doesn't work with nested collections with large depth decaporg/decap-cms#7460

[kyoshino]

I see https://codeberg.org/forgejo/forgejo/pulls/8179 has been merged.

Looking at the API design, I think this will work: https://github.com/sveltia/sveltia-cms/compare/forgejo-backend

[kyoshino]

Retrieving files is fine, but saving changes doesn’t work because of https://codeberg.org/forgejo/forgejo/pulls/8139. I know Gitea doesn’t enforce the SHA option in contrast to the doc.

[oliverpool]

@kyoshino you are too fast!

I wanted to draft a PR with an example to ease your work, but you beat me to it…

Anyway feel free to experiment on https://v12.next.forgejo.org/ (which already contains the feature - deployed nightly).

Yes, the sha check is to prevent unknowingly overwriting changes. It can be addressed in 2 ways:

• either by sending the blob-sha (it currently works for the first edit with minimal changes, but not for subsequent ones since the updated sha is not easily saved)
• or by sending the commit sha (the edit will be accepted if the commits that happened in the meantime did not touch this file)

[kyoshino]

Yeah, I could update a file by sending the SHA. But subsequent updates fail due to some bugs in Sveltia. I’ll fix them and ship the Forgejo support probably next week.

[kyoshino]

Sorry to keep you waiting, folks/forks. I know Forgejo 12 is shipping next week. I’m on track to release the Forgejo backend in the coming days.