Migrating to Gitea

wn_name · 2021-01-23T13:19:12.375Z

On POSTs for settings (2fa, access tokens, etc.) I was getting “Invalid csrf token.” with a HTTP 400 response. Clearing cookies (presumably some leftover Gogs stuff) for git.tt-rss.org fixed the issue.

fox · 2021-01-23T13:22:17.026Z

yeah, same here. not sure if needs some kind of fixing.

fox · 2021-01-23T21:55:44.745Z

apparently gitea has a very peculiar approach to repository creation limits:

github.com/go-gitea/gitea

Proposal: fork count limit

opened 09:27AM - 01 Aug 18 UTC

SagePtr

kind/proposal

- Gitea version (or commit ref): ced08d1 - Git version: 2.15.1 - Operating sys…tem: Linux - Database (use `[x]`): - [ ] PostgreSQL - [x] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] Not relevant (server is down) - Log gist: ## Description How to reproduce: 1. Create new user. 2. Set repository limit to 0 for this user. 3. Try to create new repo (limit reached, repo won't be created). 4. Try to fork existing repo - repo will be forked successfully, resulting user having more repos than he is limited to.

so its back to janitoring spam, i guess.

JustAMacUser · 2021-01-23T22:45:32.842Z

Lot of discussion in that ticket for what is effectively a minor, no-brainer issue. If you put a limit on something, you put a limit on something. Any workaround just lets people cheat the system.

SagePtr:

With unlimited fork feature, repo limit has no sense because user can fork any repo, clean fork’s content and use it as he wants.

fox · 2021-01-23T23:12:18.580Z

yeah, this people are incredibly naïve if this scenario wasn’t immediately obvious to them.

anonymous · 2021-01-27T09:35:38.337Z

Fwiw, recaptcha is blocked in China. It’s likely that people who can install ttrss, know how to deal with it, but to just let you know.

fox · 2021-02-06T06:37:49.455Z

Gitea has started to run out of its allocated memory quota of 512MB:

gitea-ttrss-docker_app_1           0.79%     443.4MiB / 512MiB     86.60%

That’s after restarting and pushing one (1) commit into the repository. I don’t really want to give it even more RAM (Gogs used to utilize about 80MB on the same setup - ???).

github.com/go-gitea/gitea

iowait and memory consumption are skyrocketing regularly

opened 06:49PM - 06 Dec 19 UTC

closed 07:01PM - 16 Dec 21 UTC

schmittlauch

performance/speed performance/memory

- Gitea version (or commit ref): 1.10.0 - Git version: 2.16.4 - Operating system: openSUSE Leap 15.1 - Database (use `[x]`): - [ ] PostgreSQL - [x] MySQL (MariaDB) - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] Not relevant - Log gist: ## Description As written earlier [in the Discourse forum](https://discourse.gitea.io/t/gitea-suddenly-consumes-all-available-memory/1465/2), it regularly happens that gitea makes my server's iowait and memory consumption skyrocket, causing issues for all other services running within the same VM. Usually only killing the whole gitea service makes the server recover. While I couldn't find any direct cause by parsing the logs or the PPROF data, I just discovered in the admin web interface (tab Monitoring) that the **GetDiffRange** operation seems to be responsible. It seems to get stuck at a single repo of just 138MiB size, clogging IO and making gitea consume more and more memory. `iotop` shows that gitea creates a lot of I/O, although I'm not sure whether swapping operations are allocated to the process causing them as well. After this issue first occured, I limited the gitea systemd service to 600MiB and gitea is currently using all of it. But apparently this limit isn't working as the memory+swap usage increased by more than 3GiB during the GetDiffRange operation. What does this **GetDiffRange** operation do? I wasn't able to find information on that. Luckily I was able to allocate an additional 1GiB of memory to my VM, giving me the chance to let the operation run. So far it's running for more than 30 minutes though. Any ideas about that operation, why it's getting stuck or any additional debug information I could provide?

so what, they can’t handle “large diffs”? lol.

i suppose the choice here is between gogs which is largely abandonware and gitea which is overbloated garbage hacked together without thinking (re: repo clone permission issue, observations on stylesheets they changed from gogs and peppered with ! important because they don’t know any better, overall ram usage, etc). what a time to be alive.

maybe i should just drop the whole thing and publish git repositories directly without a shitty web ui on top of them.

imgx64 · 2021-02-06T14:28:56.221Z

Do you use any features of gitlab/gogs/gitea other than merge requests?

fox · 2021-02-06T14:40:09.735Z

wiki, gitea has a proper editor for it (gogs doesn’t, iirc).

fox · 2021-02-07T18:02:08.843Z

I’d like to add that my RAM issue seems to be mostly solved, with more improvements coming in newer Gitea versions:

github.com/go-gitea/gitea

after upgrade to 1.13.0+rc2 consumes too much memory

opened 03:11PM - 27 Nov 20 UTC

closed 02:21AM - 19 Feb 21 UTC

kuznetz

kind/question

- Gitea version (or commit ref): 1.13.0+rc2 - Git version: 2.26.2 - Operating system: official docker, hosted on Debian GNU/Linux 10 (buster) - Database (use `[x]`): - [ ] PostgreSQL - [x] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [x] No - Log gist: ## Description After upgrading version from 1.12 (to fix issue #13605), new version takes all avaliable (~1,5GB) memory, and falling docker host. After limiting to 512MB in docker configuration, gitea reach maximum and not respond to git or web browser. It allocating memory by 50-10MB, each 1-3 min, until reach maximum. After 10-15 min after overflow, it looks like the server is restarting and the loop repeats. Past version consumes ~200mb with similar repos. ## Screenshots

So, it’s not that bad. I’ve also reported some kind of minor thing to Gogs issue tracker a few weeks ago and haven’t received any replies. This was the major reason to drop it, btw. Can’t stand being ignored.

e: btw if someone needs it, apparently Gitea has a dark theme. i’ve enabled it.

Luke · 2021-02-08T13:08:04.640Z

Me, I’m Zen. I’ve given up. If an app needs more RAM, by god it will get more RAM. I can’t be bothered anymore. Although sometimes I wake up trembling and wondering where my 386SX with 4MB of RAM went…

fox · 2021-02-08T13:18:12.921Z

well, for this vps it’s either limit container and enjoy it crashing or don’t and play OOM killer roulette.

Server Uptime

17 hours, 43 minutes, 18 seconds

so far so good etc.

johnjaylward · 2021-03-22T23:42:02.319Z

fox:

When you do, post here so I’d bump your repository limit, same as before

I just re-registered as johnjaylward

fox · 2021-05-28T17:24:09.063Z

amazon bot decided to visit git.tt-rss.org today and started requesting pages randomly. surprising nobody, this caused gitea to spawn hundreds of zombie git processes, shit itself, and die, repeatedly:

$ cat zombie_git_processes.txt | wc -l
253

i’ve switched all git repositories to be served directly by nginx with git-http-backend as needed. which, again surprising nobody, caused a significant LA drop on the vps where git.tt-rss.org is running.

i’ve tried a bunch of repo urls and it seems to work fine, but if something got broken, post here.

i suppose another bot or any kind of load, really, can cause gitea to do this again but as long as git repositories are working for everyone, it’s not a big deal.

Athanasius · 2021-05-28T18:36:59.950Z

I was able to fork the googlereaderkeys repo now, but I’m having trouble pushing my changes up to my fork.

Is there a recommended, tested to be working, method for this?

I had:

Added an SSH key
Copied the ssh URL for the fork: git@git.tt-rss.org:Athanasius/ttrss-googlereaderkeys.git
git remote add athanasius git@git.tt-rss.org:Athanasius/ttrss-googlereaderkeys.git
But git push athanasius just hangs, as indeed does ssh -v git@git.tt-rss.org

Using the HTTPS URL and my website login credentials does work, but it’s not exactly convenient. I can live with it if needs be.

fox · 2021-05-28T18:51:40.790Z

unfortunately you won’t be able to use ssh because git.tt-rss.org is behind cloudflare.

also you don’t need to use git.tt-rss.org unless you plan to contribute code back to my branches, just use github or whatever site is convenient. it isn’t really a general purpose hosting.

Athanasius · 2021-05-28T19:14:25.054Z

I figured it would be something like that. And I suppose there’s no easy way for you to disable showing the SSH options on cloning and the like.

I PR’d because you split googlereaderkeys into a repo your end rather than drop it entirely, so might as well maintain my changes along with yours.

wfriesen · 2021-05-28T20:02:43.531Z

Thanks for your efforts. If you keep maintaining this, do you plan to keep submitting PRs to the fox repo here or somewhere else?

Athanasius · 2021-05-28T20:38:45.849Z

So long as fox keeps googlereaderkeys as a repo his end I’ll always contribute changes to it via Pull Requests.

I don’t use all the keybinds it changes/adds, so give me a prod if anything needs tweaking.

wfriesen · 2021-05-28T20:55:42.840Z

Athanasius:

I don’t use all the keybinds it changes/adds, so give me a prod if anything needs tweaking.

I only really use j/k/v/ga/gs, and only update weekly. If I notice any of those keys break I’ll try to send a PR myself.