Hacker News Reader

Comment by kstrauser | Hacker News Reader

I’ve migrated over the years from Gogs to Gitea to Forgejo. It’s such an excellent piece of software.

90% of the time, I can get by with hosting my personal git repos on an SSH server I have. When all I’m trying to do is put my Chezmoi repo somewhere that all my computers can access it, Forgejo and friends don’t add much to it. For the 10% of the time when I want to share my code privately with some friends it’s brilliant (and free beats a GitHub paid plan). And if I’m going to have it running anyway for those 10% projects, might as well use it as my personal git repo of record for everything else, too.

View on HN

For my projects I have been using Onedev https://github.com/theonedev/onedev which has also kanban and code editor

You run that locally on your own machine, or you host it yourself somewhere? If the latter, you just stop programming fully if the internet connection for whatever reason doesn't work?

I'd never consider running my code editor as infrastructure, but certainly interesting to see that others seems to do.

I've used Github's built in VSCode for quick one-line PRs or docs cleanup. I'm lazy enough to appreciate the feature even if I would never do deeper work in it.

I just install the container remotely, cicd remotely etc and code locally. My use case is the opposite, I might need to do some adhoc support and not have the laptop with me so then I use the online code editor

> If the latter, you just stop programming fully if the internet connection for whatever reason doesn't work?

It's privilege and probably a dose of luck but I can tally up on one hand the number of hours my house and/or phone hasn't had internet in the last 5 years, including total power losses. I also wouldn't run my editor as a hosted service but I can understand why someone in a similar position might take that gamble. It's certainly no bigger of a risk to me than being limited to working on something physically at a workplace and needing to rely on transportation to get there, which also has maintenance concerns and infrastructure congestion and reliability issues that have caused more productivity losses to me than my utility providers ever have.

Not my thing but I see why others would like it. Forgejo is freaking tiny by comparison resource-wise, though. It’s a Go program that runs comfortably on a Raspberry Pi with a dozen other services. That alone makes it super attractive to drop onto any spare computer you have laying around.

My first stab at running a git server was Gitlab CE (because I was using it at work.) I tried running it on an Atom based server with insufficient RAM and it just crawled. Page loads just timed out. I switched to Gitea and it was a breath of fresh air.

Forgejo got to my attention when Fedora chose it for their repo server. My needs are pretty simple - just some centralized file storage of notes and some source code. I've tested a migration from Gitea 1.21 to Forgejo 9 and it was frictionless.

I'm seriously consider migrating, but I still wonder which will be better supported (and suitable for free-as-in-beer use) in the long run.

I wonder about that, too. I’m still on Forgejo 7 which hasn’t diverged too much from Gitea, but there’s going to be a decision point soon.

When I looked recently, it looked like Forgejo was getting much more activity. If I had to guess, I think it’s going to be the leading fork.

Gitea 1.22 will be the last release with guaranteed migration support to Forgejo. The next Forgejo LTS release, v11, is due out around April. Migration from Gitea 1.23 will not be supported, and since it was released in December those on the fence are now at the fork in the road.

You still have time to figure out what to do, but you'll need to choose sooner than later.

https://forgejo.org/2024-12-gitea-compatibility/

Thanks for that. I hadn't followed closely because right now I don't have a real desire to go back to Gitea. I'm glad to know that deadline to commit is coming up soon.

Yes, I'm aware of that. I'm on a Gitea version that will migrate easily (and have confirmed that) and will not upgrade or migrate until I have decided. (I am leaning toward migrating to Forgejo.)

Did you notice any important differences between gitea and forgejo (besides ideology)? Although it seems like forgejo has added actions in the meantime

Gitea also has actions.

https://docs.gitea.com/usage/actions/overview

Gitea actually got actions before Forgejo did. That was part of what motivated Forgejo to become a hard fork instead of just a rebrand—there was some sort of disagreement about the way in which actions were rolled out and Forgejo decided from there to stop trying to be fully compatible.

https://forgejo.org/2024-02-forking-forward/#the-hard-forkin...

I've missed that part. AFAIK both are forked from nektos/act and can't be dramatically different. All this story is an unnecessary dichotomy for me. Still hosting production code on a Gitea instance and will happily pay a dime but didn't get why yet.

I probably worded that wrong, but that was my point. Forgejo didn't have actions for the longest time, so I was wondering if it "caught" up with gitea

Not a thing. I don’t use actions yet, just the primary repo management UI. I don’t know if I could tell the difference.

I initially had a Gogs install, but moved to GitLab because of GitLab CI and some other features. It was a bit too heavyweight in comparison and the updates became difficult to keep up with, so I eventually moved over to Gitea and Drone CI (some might also like the Woodpecker CI project).

Honestly, my eventual next move will be either Forgejo with their Actions https://forgejo.org/docs/next/user/actions/ for CI/CD or maybe going off into the deep end with moving back to Jenkins.

For me GitLab CI is a reason to move _away_ from it.

Really? What’d you dislike the most about it? In my experience, the syntax was actually more user friendly than that of GitHub Actions and the file based approach a bit easier to carry across projects than what Jenkins and the likes do.

Drone CI and Woodpecker both felt similar in that regard, at least to me. Though the docs of GitLab CI definitely make me consider it for group projects across an org.

One of my biggest headaches is that the pipeline cache never seemed to work predictably (e.g. not pulling cached data that was available, it uses zip so the permissions are messed up, etc), so I ended up writing my own caching system. It was important for my use case because full runs could take 2 to 3 hours.

Then there is the YAML config which is too convoluted. It took me several attempts to get things right.

What works better, IMO, is to have each CI step as a script or a Make target that can run anywhere (CI or dev PC) and in the CI configuration have a single line in each step that invokes the script.

I will never go back to Jenkins. It was my job across several shops over the last decade to keep that thing slogging along and I’m beyond done with it.

Reply on news.ycombinator.com