Skip to main content

Move to Gitea

Hi !Friendica Developers,

how close are we to move to Gitea? I may lose access to GitHub in April because of their stupid password policy and my stubbornness not to comply with stupid policies.

Add to that the fact it now belongs to Microsoft and it's a question of time before some or all of it becomes either paying or restricted to use with Microsoft products.

I'm aware of the cost of such a move for the project visibility but circumstances are pressing and I may lose the ability to contribute to issues and PRs.
All github workflow dependencies are now successfully moved to drone ;-)
Thanks for the update, does this mean we could seamlessly move to Gitea?
@Hypolite Petovan @Philipp Holzer I guess not seamlessly ;-) I cloned the friendica/docker repository last year to friendica/testdocker at gitea. The repo was not synced since then, so you can see the snapshot from a year ago. tickets and closed PRs.

I think I'll need to remove the old mirrors and recreate the repositories without the syncing and from the moment of the move that repository / ticket collection etc will be the reference one for our usage. The github repo will stay untouched from that.

Maybe start with some unimportent repositories (the directory maybe) after the release but ahead of the hackathon?
@Hypolite Petovan @Philipp Holzer I've cloned the "friendica-directory" repository to gitea, including issues, wiki etc..

It is not a mirror, so work on this should likely be done now at gitea.
Thanks, I’ve received an issue somewhat recently at friendica-directory, I’ll try the whole issue-PR workflow this week
@Hypolite Petovan yep, this one I have not archived the repository on github yet... but I think even if there is another issue reported it should be ok to test with.
@Hypolite Petovan I just then need to know:
- Push/pull URL(s)
- where to sign up to report bugs or put PR ups
- how to put PRs up (still the old way?)
@Roland HΓ€der the repository structure at mirrors the structure at github. So when you are currently pulling from you would then pull from

At the moment random signed up users have a limit for newly created repositories, but core and addons is possible. To raise this limit one has to contact the gitea admins.
the fact it now belongs to Microsoft

They made such an effort and gave everyone a batch of achievement when they snapshoted all the code for cold storage... πŸ˜‚

Joking aside, I don't think the project's visibility would be greatly reduced by a move to Gitea. If needed, a "landing page" or archive with a link to the current repository could still be retained at GitHub.

A key concern is reliability and robustness of the new Gitea set up though.
I measure this reliability by the frequency of test failures caused by the unavailability of one of our Composer dependencies which happen to be hosted there. And I don't remember any such instance in quite a while, @utzer did a fine job overhauling the server.
Nice! That's great.
I think we also have several mirrors of running around the world.
My mirror is currently linked to GitHub. But I can easily switch the mirror source to our Gitea repo as soon as that one is used as main repo.
@Hypolite Petovan @Andy H3 ah, only the old server was slow... the new one is much fast, mainly IO is faster. Main work is done by @Philipp Holzer, not me.
OK. That's the point of reliability that Hypolite began to address. Software/ hardware being in an acceptable state; sensible server backup in case of a server problem, etc.

For the broader term of "robustness", we may need to ask what else is in place to address other points of failure/ ability to recover.

E.g. the server operator has a temporary memory loss and forgets to pay the provider for the server space.... the instance gets eventually deleted including all the code.

How many upda-to-date mirrors do we have running and where?

Any other important points to think of?
@Andy H3 @Hypolite Petovan @Philipp Holzer I do a daily backup, if anyone is interested he/she can have a backup for the server, I just need SSH accessible space and will run a backup onto that space and provide the borg key for the backup.
@utzer can you send me a/your public ssh key? I will add it to a new account of my (hetzner) storage box and create a sub-directory for the friendica sources for you :-)
This entry was edited (1 week ago)
@Philipp Holzer just realized it is easier if you look for the key in .ssh yourself. :-P
I'm mirroring here:

Steffen mirrors here:

Both of us are currently only mirroring the code there. Gitea however also allows mirroring repositories to include issues, labels, merge requests, releases, wiki. This requires an access token to the host.

I'm currently not sure what the security implications are about given out access token. This still needs to be clarified.

2 people reshared this

@Andy H3 @Hypolite Petovan @Friendica Developers I already mirror a friendica and addons on my Gitea, happy to mirror whatever is needed as I have plenty of space.
@Tobias we also need to check the SSH access for gitea? I guess some people are using SSH for pushing maybe? Or is https ok?
This entry was edited (1 week ago)
@utzer good question :P I'm using https and that works. I've never actually thought about ssh o.O we'll see ;-)
Have you ever tried to push to Gitea from a local clone? Usually HTTPS is limited to pulling.
@Tobias problem is, 22 is taken... and well, for many people IPv6 is too new and too fancy. :-D
@utzer jepp, ssh does currently not work... something for the tinker list :) there is also a "interesting" localhost in the ssh path to be used, so that needs definitively some work and thinking before.
@utzer I did a quick look and it seems that we can use gitea build in ssh server with any port we like. I've also found that localhost in the config :-) Pick a port and let me know about your pick, then I'll try changing the gitea config accordingly.
@Tobias I think for this I have to shutdown the vps, rare task.

@Philipp Holzer here I would see running checks, which now run against gitea or still against github?

@Tobias wondering when the time is good to shutdown and then directly restart the server.
@utzer the tests are all done with our Drone now but they are done only on reporistories that are on github at the moment.

Best time? Don't know ;-) OTOH you are restarting the server, it's not a long downtime, so it should not have a big impact I guess.
@Tobias ok, backup, update and restart are done, check port 50222.
@utzer I'll have a look this evening
I've been able to transfer the remotes from GitHub to Gitea on both the production directory and my local clone to my own fork on Gitea. I've also been able to push a new branch on my fork. I've been surprised not to be prompted for authentication but I set up application keys to interact with Gitea three years ago!

I'll keep on the issue-resolving workflow and I'll report any success or failure.
I had to create a new filter rule for my mail client @Hypolite Petovan \o/
I managed to create a release for friendica-directory:

But I can't upload the usual project archive to Gitea because it now is larger than 4MB. Not sure if the limit is set at the Gitea level or at the PHP level on the machine.
@Hypolite Petovan likely some default value we have not touched yet because there was no need to think about such a limit ;-) I'll put it on my ToDo list
@utzer is it possible, that the 4MB upload limit are coming from the proxy leading to the gitea instance? gitea had a limit of 3MB which I raised to 10MB (for now and testing) and the local nginx had no limit set. Could you have a look?
@Tobias could be. Not sure. What is default for Nginx?
I can increase that.
This entry was edited (5 days ago)
It looked like a limitation set by Gitea (or the underlying PHP platform), not by nginx. I didn't get a web server error, I got a nicely formatted Gitea error.
@Hypolite Petovan @utzer but gitea should have nothing to do with PHP, and go has no global config AFAIK However something to look into again later ;-)