Support for Gitea

[a-akimov]

Currently, Netlify CMS works only with GitHub, while for many companies this might be not the best option. It would be great if Netlify CMS can also support Gitea (https://github.com/go-gitea/gitea)

[talves]

@a-akimov NetlifyCMS currently has an option to register your own backend and be able to add your own backend project.

I created a shell example of the backend for file-system in this repository.

Anyone can make a backend the same way as GitHub by using the code in the GitHub backend as an example and replacing the src in my backend example.

There will be NetlifyCMS supported backends going forward, but Gitea would probably need to be a community supported backend in the future.

[talves]

@erquhart do you think this issue should be a NetlifyCMS maintained feature (mono-repo) or would this be something we leave open for someone to take on outside the project as I suggested?

[erquhart]

Community, but we can leave this open for visibility.

[techknowlogick]

Gitea now supports OAuth (will be officially released soon, but for those running nightlies you can use it already): go-gitea/gitea#5378 so this may be easier to implement.

[gsantner]

Is there any news on this? Did some subscriber of this issue maybe already work out something for his Gitea installation?

[lunny]

This is a good reason why gitea does not have pages like gitlab or github has.

[erquhart]

No news yet @gsantner. As @talves mentioned, it comes down to creating a backend for Gitea, similar to the backends for GitHub, GitLab, and Bitbucket.

[lunny]

I sent a PR igk1972/netlify-cms-oauth-provider-go#9 but don't know that's the right place.

[erquhart]

Nice! If that works, it will allow that library to handle authentication for Gitea, but you would still need a Gitea backend - check out the gitlab backend to see what that looks like:

https://github.com/netlify/netlify-cms/tree/master/packages/netlify-cms-backend-gitlab

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ghost]

Any update on this?

[erezrokah]

Hi @crone11, best way to get this prioritized is up vote the issue as we try to do the most up voted ones first.
Another option is to submit it as a PR (you can use #3318) as a reference.

[ShalokShalom]

At the current time is Gitlab the only open source solution and that one is slow and I personally dislike it.

The goal of this project is to open source the "CMS for static page" idea and so I think it is important to add choice to the backend.

Really hope this becomes realized.

[erezrokah]

Hi @ShalokShalom we would gladly accept a contribution for this. We have one ongoing for Azure:
#3318
One could use the GitHub one as a reference https://github.com/netlify/netlify-cms/tree/master/packages/netlify-cms-backend-github

[DevAhmedRagab]

Any update ?!

[erezrokah]

Hi @DevAhmedRagab, see my comment here. It would be great if someone can continue the work done in #4384

[Aeradon]

Bump! I just found myself in the exact position OP described. We are thinking on using staticCMS as they have a beta support for Gitea right now. Maybe it would be possible to port that functionality from staticCMS to netlify cms, as one is a fork of the other?

[denyskon]

@Aeradon

I authored the Gitea backend for Static CMS 🙃
I can definitely say it would be possible to port it over, but it seems like development of Netlify CMS has stopped and I wonder if a PR would ever be accepted.

[About7Deaths]

@denyskon Just noticed that they rebranded to "Decap CMS" within the last 2 weeks. Now may be the time to strike?

[denyskon]

@denyskon Just noticed that they rebranded to "Decap CMS" within the last 2 weeks. Now may be the time to strike?

Yeah, I'm densely following what's happening. The Decap team has announced that they want to resolve dependency issues as their first step, so I would like to wait till that is done. At least for me, Netlify CMS didn't build the last time I tried.

When the problems will be resolved, I could easily port over the backend.

But in any case, because of go-gitea/gitea#14619 I wouldn't consider the backend production-ready.....

[gfauredev]

I’m not sure to have the knowledge to port Gitea support by myself, but I’m interested to help if needed.

[denyskon]

I’m not sure to have the knowledge to port Gitea support by myself, but I’m interested to help if needed.

Oh it isn't much, I'd manage it on my own. Just want to wait for the updated codebase :)

[gfauredev]

Gitea now supports OAuth (will be officially released soon, but for those running nightlies you can use it already): go-gitea/gitea#5378 so this may be easier to implement.

Ok, and do you think this could exempt the use of an additional server ?

[denyskon]

Gitea now supports OAuth (will be officially released soon, but for those running nightlies you can use it already): go-gitea/gitea#5378 so this may be easier to implement.

Ok, and do you think this could exempt the use of an additional server ?

Netlify Identity doesn't support Gitea, so we do need an own OAuth provider. I have created one (https://github.com/denyskon/teabag) for myself because I also use Static CMS with Gitea. Currently I didn't see any alternatives.

-- expalination --
Auth flow in Decap always works through a third party oauth provider, because in Decap we don't have the possibility to safely store a client id and secret. Normally Netlify is used for that.

[jimafisk]

Gitea OAuth supposedly supports PKCE so you shouldn't need a secret and would be able to authenticate without a separate server (like you can do with GitLab).

However, I'm trying to do this for a similar project (Plenti) and not having much luck: https://discourse.gitea.io/t/oauth-pkce-example/6573

[gfauredev]

If I understand well, the client-side PKCE auth process as described in the DecapCMS docs is not feasible with Gitea OAuth ?

Edit :
Ok, it should be possible to authenticate without a separate server but it’s not an easy task.

[jimafisk]

In that same Gitea doc at the top under Supported OAuth2 Grants it lists PKCE. Getting it to work however...

it should be possible to authenticate without a separate server but it’s not an easy task.

This was relatively straightforward to implement with GitLab. I'm just not sure if the PKCE grant is actually working in Gitea. I can't find any working examples or support, but more voices asking for the same couldn't hurt!

[denyskon]

Gitea OAuth supposedly supports PKCE so you shouldn't need a secret and would be able to authenticate without a separate server (like you can do with GitLab).

However, I'm trying to do this for a similar project (Plenti) and not having much luck: https://discourse.gitea.io/t/oauth-pkce-example/6573

I tried to implement it, but unfortunately Gitea still requires a client secret if doing PKCE. There also is an issue open for that (go-gitea/gitea#17107) but it seems to have stayed unnoticed till now.

[denyskon]

I ended up opening a PR for Gitea to create an API endpoint allowing to modify multiple files (go-gitea/gitea#24887). This will make implementing the backend a lot easier and allow for it to work in a more elegant way. When I know in which state it will be merged, I will hopefully soon be able to finally create a PR for Decap.

(cc @jimafisk)

[denyskon]

If go-gitea/gitea#25033 gets merged we can also have GitLab-like PKCE as the last missing part 🙂

[jimafisk]

@denyskon just want to express huge appreciation to you for picking up and running with both these critical features. Thank you!

[denyskon]

Both PRs are merged now for Gitea 1.20 which will be released near the end of June/start of July. I'll try to finish the backend until then so if Decap decides to publish a release shortly after, it'll be ready.
Basically both features merged means that we don't need an additional oauth provider anymore and also that the way we would edit files over API is more production-ready.
Let's see what happens :)

[denyskon]

@martinjagodic How should the package be named? netlify-cms-backend-gitea or decap-cms-backend-gitea ?

[martinjagodic]

Let's go with netlify, we will rename them all together later.

[denyskon]

A problem currently is that Gitea doesn't support all the features need for the editorial workflow, but it seems to be required to provide the functions in the backend implementation.
If I don't overlook something, there is no way to define a workflow as not supporting editorial workflow? If so, would you be open to implementing such an option?
Otherwise we would need at least one other new API endpoint on the Gitea side (branch comparison)

[erezrokah]

If I don't overlook something, there is no way to define a workflow as not supporting editorial workflow? If so, would you be open to implementing such an option?

Hi 👋 As the former maintainer I believe you could have a backend not supporting editorial workflow. The local backend does it by default.

I think you could throw an error in the backend ctor if the publish mode is editorial workflow, and give a stub (error throwing) implementation for the relevant editorial workflow methods to make TypeScript happy.
You could use

decap-cms/packages/netlify-cms-proxy-server/src/middlewares/localFs/index.ts

Line 42 in aaece1d

case 'entriesByFolder': {

as a reference of the minimal set of methods needed for a backend implementation.

I hope that helps

[denyskon]

If I don't overlook something, there is no way to define a workflow as not supporting editorial workflow? If so, would you be open to implementing such an option?

Hi 👋 As the former maintainer I believe you could have a backend not supporting editorial workflow. The local backend does it by default.

I think you could throw an error in the backend ctor if the publish mode is editorial workflow, and give a stub (error throwing) implementation for the relevant editorial workflow methods to make TypeScript happy.
You could use

decap-cms/packages/netlify-cms-proxy-server/src/middlewares/localFs/index.ts

Line 42 in aaece1d

case 'entriesByFolder': {

as a reference of the minimal set of methods needed for a backend implementation.

I hope that helps

Hi! Thanks, I will try it. If the CMS doesn't rely on that methods, it shouldn't be a problem.
I believe you know what you say as you initially rebuilt that component 🙂

[denyskon]

I think the PR is ready. It would be nice if somebody would test it before it can be merged. There is a prepared config for https://try.gitea.io in dev-test, you'd just need to create a repo and adjust the config accordingly.