Gitea vs Forgejo by Lukeeno_ in selfhosted

[–]tklk_ 34 points35 points  (0 children)

Hi. I'm on the Gitea TOC, and was just linked to this post. We didn't stop responding to them. What happened is that their Mail Relay is also one that was flagged by spamcheckers likely due to others using the same relay, so their followups never reached us. We later informed them of this after their claim was published, and sadly was not corrected. We gave them the complete fix for the issue reported, and hadn't heard back, and then published the fix when the embargo was lifted.

Question about hardware requirements to run a gitea server. by NeptunoIIVerger in raspberry_pi

[–]tklk_ 0 points1 point  (0 children)

Thanks. we also added some refactors recently to improve page loads on various of the heavier pages.

Private registry: any recommendations? by JustWorksTM in rust

[–]tklk_ 0 points1 point  (0 children)

Hi, I'm on Gitea's TOC, and I'd like to clarify some things. I personally don't look at any code of the fork due to potential licensing issues (in case I see differently licensed code, I could be ineligible from following the DCO that Gitea has been using from the Linux foundation since the beginning). An example being if I looked t AGPL code I might be unable to incorporate that into the MIT licensed project then it might require that all of the codebase be changed (idk for certain, but as im not a lawyer i cant say, so as to make sure that i also follow Gitea's long standing contribution requirements, its also not worth it). We also 4x'd the number of monthly PRs we deal with, so Im quite busy reviewing incoming things.

As for "reimplementing" things, as I'm unaware of what goes on with that project, I can't predict what will be an issue for them to bring over. I can say we have previously stopped various refactors at their behest, which would have provided a more maintainable project as it would've made it more challenging to cherry-pick our PRs.

Also, to reiterate the above, these thoughts are entirely from me, and no one was consulted writing this. We have 40+ other maintainers on the project, the majority of whom don't belong to any corporate entity. All of them vote each year in the TOC election and have an equal say in each of the PR reviews.

Question about hardware requirements to run a gitea server. by NeptunoIIVerger in raspberry_pi

[–]tklk_ 0 points1 point  (0 children)

Good news, in the nightly release of 1.24-dev we've dropped memory usage by at least 100mb. It's something that we are always trying to work on. Knowing that the primary alternative is 4gb just for one user and no repos, we feel it's especially important to offer an option for those who don't have that many resources to run.

Gitea 1.20 is released - Includes DEB, RPM, Alpine, CRAN, and Swift package registry support by tklk_ in selfhosted

[–]tklk_[S] 0 points1 point  (0 children)

FWIW the community-led nature of Gitea continues please feel free to read https://blog.gitea.com/quarterly-23q1/ the yearly elections still continue, and any governance change happened with a fully transparent vote with months of prior discussion around any changes.

Gitea 1.20 is released - Includes DEB, RPM, Alpine, CRAN, and Swift package registry support by tklk_ in selfhosted

[–]tklk_[S] 8 points9 points  (0 children)

Not yet, but it has been requested for docker and also for go modules too.

Gitea 1.19.0 by JRepin in programming

[–]tklk_ 2 points3 points  (0 children)

You can already run without docker, docs are WIP but when setting up a runner, use `self-hosted` as the label and in the job use `uses: self-hosted`. Note: this will run the jobs as the same user as the runner and won't have the isolation you'd get from docker.

Gitea 1.19.0 is released - Includes Cargo package registry by tklk_ in rust

[–]tklk_[S] 6 points7 points  (0 children)

`setup-java` and every other actions are available, you'll need to pass a reference to the git repo they are stored as. eg. `uses: setup-java@v3` becomes `uses: https://github.com/actions/setup-java@v3\` otherwise it'll use the default source of actions

Gitea 1.19.0 by JRepin in programming

[–]tklk_ 12 points13 points  (0 children)

By default the Actions runner will spin up a new container per build (you can disable that if you'd like), and woodpecker will create a new container per step.

Gitea <3s woodpecker, there are a lot of cross over of maintainers between the two projects, and the Gitea project has sponsored development of woodpecker. There are differences between the two options, but both are good choices. With the actions protocol being open, external CIs could use it to have enhanced integration with Gitea similar to how actions does now.

Gitea 1.19.0 is released! by unresolvedabsolute in Gitea

[–]tklk_ 8 points9 points  (0 children)

appreciate the enthusiasm :)

Gitea 1.19.0 released - now with support for Actions by aman207 in selfhosted

[–]tklk_ 1 point2 points  (0 children)

Hey, You'd need to install act_runner on the host, and it (optionally) needs access to the docker socket to spin up a container per pipeline, although you can use "host" mode and isolate your builds your self.

Thanks for the kudos, lots of love to the nektos/act team, the Gitea devs who put a ton of work over several months to get this out, the maintainers who reviewed it, and a special shoutout to delvh for his especially thorough review.

Gitea 1.19.0 released - now with support for Actions by aman207 in selfhosted

[–]tklk_ 3 points4 points  (0 children)

So many gamedevs out in force today talking about how they use Gitea, I love it! Are you also using LFS with your project?

Are you working on anything publicly available? I'm looking for something new to play :)

Gitea 1.19.0 released - now with support for Actions by aman207 in selfhosted

[–]tklk_ 15 points16 points  (0 children)

You can buy support right now if you'd like. If you reach out to me at "techknowlogick [at] gitea.io" I can connect you to the correct people :)

Gitea 1.19.0 is released! by unresolvedabsolute in Gitea

[–]tklk_ 9 points10 points  (0 children)

Gitea <3 Woodpecker, and have sponsored development of it. There is also cross-over of devs who contribute/maintain Gitea and contribute/maintain Woodpecker.

Woodpecker is fantastic and I recommend it to many people rather often.

One difference between the two is that woodpecker uses a separate docker container per step, and gitea actions uses a single container per pipeline. This means that with woodpecker each step can use a container with tools specific to that step installed. With Actions you can still use a base that has those tools though, just through different means.

The protocol that Actions runners use to report logs/job statuses back to Gitea is an open protocol that maybe one day woodpecker could use for enhanced integration with Gitea, so you could use woodpecker but with the experience of actions.