Really excited for Gitea Actions!! Will probably look into switching from GitHub now. Wasn't a fan of drone or having to maintain the integration with a separate CI/CD system.
Gitea actions looks neat though I'm not sure how you are meant to run windows or mac-centric workflows with it since the runtime (nektos/act) seems to require docker. If its not possible that might limit its usefulness somewhat...
Alternatively, I was wondering if it supported podman. I prefer podman in most cases since it runs without root and doesn't mess with my host's nftables. Docker always invokes iptables and adds a bunch of chains/rules. Grrr...
Don't do it yet otherwise you will fill disappointed by teething problems. Do it in 3 months and then - if they keep the current dynamics - you will be able to work with GA more comfortably and only encounter minor bugs.
It's mindblowing for me how many of the features I love from github are now in gitea. Actions, email replies, scoped lables, fine-tunable access tokens, secrets and also the ability to push local git repos to gitea without having to create them via the web interface first.
> Wasn't a fan of drone or having to maintain the integration with a separate CI/CD system.
I'm in the opposite camp, especially when this separate system is as simple as Drone CI or Woodpecker CI (I mostly use the former, but the latter is more permissive, license wise). I came to holding this view after I ran into some issues by using a self-hosted GitLab Omnibus install previously: https://blog.kronis.dev/articles/goodbye-gitlab-hello-gitea-...
Using separate systems for working with the code, doing CI/CD and storing artifacts made each of the parts easier to update, limit the resources available to each, as well as limited the fallout when something does go wrong - say, still being able to interact with the codebase, even if the container repo is temporarily unavailable, or vice versa.
That said, in a few years I might come around to holding the opposite views again - frankly, both approaches are good and seeing the Gitea Actions project is nice! Though I'll also acknowledge that some might claim that all-in-one solutions are sometimes a bit half-baked, a criticism that I've heard of GitLab in the past (though honestly they're also fine, especially for the more enterprise settings, where you have beefier servers and a few people to manage the install).
I'm with you on this.
I would expand this further yet and say that introducing this as a feature creates a whole set of security concerns that just weren't there before.
Concur. Composability, separation of concerns, do one thing and one thing well, etc. are all philosophies as old as time in this industry. Any programmer worth their salt would understand the value they provide. Source code hosting has nothing to do with building your software and it's a bad idea to mix them up.
This situation is actually a bit more insidious. All these CI/CD features are just a thinly veiled attempt at locking users into the platform. There's not big money to be made selling git hosting, but if you control how the software is built, then you have made yourself a hard dependency. If you look at the starter workflows they provide, they encourage bad practices where your application build is defined in their DSL. Experienced programmers might steer away from such usage, but many novice won't. If you have enough novice adoption, it becomes the norm. So many projects these days cannot even be built locally without a CI service dependency, where instead 99% of the time, all you needed was a simple makefile.
With a large project unless a large auditor goes into your code and reads it with a fine comb it's not a good idea to have blind trust in it.
And Chinese author does mean CCP, assuming they live in China they are almost certainly able to be compromised and it is a bad decision to trust them with something as valuable as your whole code base.
If you have evidence of foul play it's already far far too late to do anything.
With authoritarian nations and their ability to control and steal your projects, you assume guilty until proven innocent. You should require there be a real audit before you trust gitea.
Half of gitea's contributors are from Europe. Wait until you learn how much "Chinese" code is in the Linux kernel these days.
This anti-Chinese hysteria is hilarious to watch from the sidelines, honestly. A few months ago there was a comment on HN by some American whose company was rewriting their frontend when they learned that antd (a React component toolkit) was developed by a Chinese company.
The people who accept pull requests and run the infrastructure of the Linux kernel aren't based on China, else I'd reject it as well.
> A few months ago there was a comment on HN by some American whose company was rewriting their frontend when they learned that antd (a React component toolkit) was developed by a Chinese company.
This is a good move. We're removing Lenovo laptops from our infrastructure here.
When we are talking about something that can be set up to silently grab code, suddenly delete your projects, if you wait until there is foul play you're waiting too long. It's like waiting for evidence of a gunshot wound.
Will be interesting to compare the velocity between the two. Can a community fork keep pace and possibly even innovate more than the commercial upstream?
There have been a few cases of open source collectives/coops that do what Gitea does but distribute the profits to contributors equally, wonder if any of those have reached sustainability.
The issue is Forgejo doesn't really have the know-how or capabilities to drive this project forward.
In the past months all they have done is rebrand Gitea and some minor fixes, but upstream (gitea) has added a huge number of features and merged tons of valuable pull requests. So are they just going to continuously merge upstream into their fork and do nothing besides that?
The platform, Codeberg might be "well" funded but not to maintain another extra project and develop new features for it.
I think the outrage was a little too big initially. It's a big task to create a git host that needs to compete with Github and the likes and I think it's fair that you want to make some money on the side with that.
> I think the outrage was a little too big initially. It's a big task to create a git host that needs to compete with Github and the likes and I think it's fair that you want to make some money on the side with that.
That seems completely irrelevant and orthogonal to the outrage though?
I'm one of the community members on the Gitea TOC.
Just to clarify, only one maintainer left the project to my knowledge, although a few other contributors did as well. The majority of us remained with the Gitea project.
No worries, that's totally understandable. The change was made mostly for practical reasons, to be able to upgrade infrastructure piece by piece. So both new and old infra could run at the same time while it was switched. I'm actually writing a blog post detailing the history of our infra, but the TLDR is that too much money and person effort was being spent on managing the infra.
Disclaimer: I am a part of the Gitea TOC, and am employed to work on Gitea.
The Forjero commits prove that this is incorrect (they are still busy removing Gitea branding related things from their code). It's going to take a long time until they begin to match the Gitea momentum.
> It's going to take a long time until they begin to match the Gitea momentum.
I'd hope so! I am not interested in many of the features being added to Gitea (i.e. the momentum you allude to[1]). I want a light binary I can continue to self-host on a Raspberry Pi Zero that doesn't have Docker installed.
1. I feel Gitea is being positioned as a competitor to GitHub and GitLab - good for them! However, the previous iteration was close to perfect for my needs, albeit not very monetizable. I'm glad it got forked and will be side-grading to Forgejo.
The momentum stalled when the community was plagued recently by toxic behaviour of one of the members who started the fork. He had to step down from the "well-being" team[1], bullied a moderation team member into stepping down[2] and forced him to disclose information from a private chat[3].
Now he is trying to "reboot" the community to erase his previous bad behaviour [4]
Forgejo members are also unhappy about conflicts of interest of this individual [5]
The Forgejo community is stronger than this one individual, so it will succeed.
It's a soft fork though, so the Forgejo folks are still relying on the Gitea team for features like this.
The Forgejo folks seem to object to Gitea on the basis that a company took the project over. I think it was that an American company took it over, not that a company took it over. They didn't AGPL forego, they just soft forked and backed the fork with a European organization instead of an American one, Codeberg[1]. Yes, the org is non-profit, but it still smacks as hypocritical.
I'll be sticking with Gitea for the foreseeable future.
I think the concern was of corporate exploitation in the name of profits, in which case I don't think forking and having a non-profit at the helm hypocritical. It's actually a very defensive position to prevent corporate interests from snatching up the project once more.
> I think it was that an American company took it over, not that a company took it over. They didn't AGPL forego, they just soft forked and backed the fork with a European organization instead of an American one, Codeberg[1]. Yes, the org is non-profit, but it still smacks as hypocritical.
Straining to assume good faith here but this seems very likely to be wilful misinfo - particularly given the emphasis. The reasons for the fork are very clearly stated in the lettter linked in the comment you're replying to: it's about community decision-making procedures (which have been removed during the incorporation). It's also about profit: the US corp is for-profit.
Secondly, not only are Codeberg a non-profit, they also adopted the project after the fork. That wasn't a part of the original letter nor discussion. They don't control the project (see aforementioned objections on the basis of democratic input) - they're a host & benefactor.
> it's about community decision-making procedures (which have been removed during the incorporation)
A quick clarification here, the new TOC is comprised of three company members and three community members, with community members having a slight advantage should there be a split vote on anything.
No, the Forgejo folks were angry that the previously community-run project was taken into ownership of a for-profit company, without any notice, and against previous promises: https://gitea-open-letter.coding.social
> They didn't AGPL forego
Uh, they CAN'T relicense it to AGPL or anything else. The Gitea authors and contributors still hold the copyright on the code, which is MIT-licensed.
You can license your fork under a different compatible license (which is most other licenses, in the case of MIT). They can't prevent people from using the versions that were already released under MIT though (and continue being released under MIT by Gitea).
Forgejo is AGPL, there was just a vote and the community came out strongly to say they disagree with commercial usage of Forgejo! I am so happy they did that!
It is sad to see that the forgejo team accept and promote the built-in CI server. When the PR was first made they said they shouldn't trust the code, and will stick with woodpecker.
It seems that they have "soft forked" act as well. I worry that they will spend more time maintaining all their forks than doing any original development...
The problem is that at this point they are just re-publishing the Gitea releases with a different name and branding. I'm all for forks when they become necessary, but is there anything there yet?
very excited about Actions. For several months I've been using a home server Gitea for a Unity project version control, because the project size is far too large for github/gitlab etc.
So far everything about it has been excellent, and it's only getting better!
As a novice at self-hosting, I previously attempted to use it, but got stuck as I didn't understand MySQL, and learning it just for Gitea was too much. However, I've had some progress with with another database recently, so I would like to give Gitea another try soon.
For small personal deployments, using SQLite as a database is usually sufficient. This means you don't need a fullblown SQL server, instead the whole database consists of a single file.
What are the current thoughts on Gitea vs Forgejo? I'm thinking of migrating from a self-hosted Gitlab to one of them in the near future. The way Gitea was taken over leaves a bad taste in my mouth so I'm leaning towards Forgejo, but it's not really clear to me if that's the right choice.
Forgejo currently is only applying branding changes and currently plans on being a soft fork. I think it’s existence is a good thing for the ecosystem (if Gitea the Company did something wonky, there will be an organized group already doing releases ready to go), but I’m not sure there is a huge benefit in running it, at this juncture.
The other discussion in this thread has convinced me that for now, the momentum seems to be with Gitea, so I'll probably lean towards that. I'm still disappointed in how the whole situation was handled, though, and it leaves me wondering what other changes will be around the corner.
I am personally not a fan of Forgejo relicensing (to AGPL). Makes the "soft fork" aspect so much harder, because anything contributed to Forgejo cannot be easily cherry picked onto Gitea.
Gitea was taken from a community run project to an corporate owned one to allow for an open core future. Currently there's been no actions taken that negatively affect the open project, but the door is now open for a "This isn't working for our company, we're now going to SSPL" style move in the future.
I am a community member of the Gitea TOC, and there will be no open core model.
Gitea will remain fully open source with no tiers.
The community TOC also has advantages in any such voting where something may negatively affect the OS project, although as you mentioned that hasn't happened yet, and I don't expect it will.
I'm super excited Gitea is becoming better and better. Gotta be honest though; the really exciting feature I'm waiting for is ActivityPub[1] support. That will really make my single gitea instance much more interesting, when I can accept PRs from other instances and make them to theirs.
A lot of comments about "Forgejo". In short: meh. Not a big deal[2]. I'll be sticking with Gitea.
This was not a company decision, it was proposed by a non-company member and approved by two other non-company members (and one company member, but just pointing out context).
Wow. Great progress! Recently, I was wondering why gitea does not have a GitHub Actions alternative. What a timing.
BTW, a colleague of mine told me that GitHub Actions wasn't supposed to be a CI/CD alternative at the time when it was released. I couldn't find any note on that online. Is it true?
I was just telling someone else how great Woodpecker is.
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 it for enhanced integration with Gitea, so you could use woodpecker but have the experience be next to your code.
Disclaimer: I am listed as a maintainer of Woodpecker. I am a also part of the Gitea TOC, and am employed to work on Gitea
They've done it, Open source GitHub Actions!
I hope politics don't get in the way of Codeberg adopting actions, as they are very involved in the woodpecker project.
Looking forward to testing it with few actions, docker-buildx and my docker-compose-gitops-action,
https://github.com/FarisZR/docker-compose-gitops-action
86 comments
[ 3.1 ms ] story [ 728 ms ] threadDisclaimer: I am a part of the Gitea project, the TOC, and am employed to work on Gitea
This is perfect for my needs. Thank you to the Gitea folks for getting this added/integrated!
Alternatively, I was wondering if it supported podman. I prefer podman in most cases since it runs without root and doesn't mess with my host's nftables. Docker always invokes iptables and adds a bunch of chains/rules. Grrr...
I'm in the opposite camp, especially when this separate system is as simple as Drone CI or Woodpecker CI (I mostly use the former, but the latter is more permissive, license wise). I came to holding this view after I ran into some issues by using a self-hosted GitLab Omnibus install previously: https://blog.kronis.dev/articles/goodbye-gitlab-hello-gitea-...
Using separate systems for working with the code, doing CI/CD and storing artifacts made each of the parts easier to update, limit the resources available to each, as well as limited the fallout when something does go wrong - say, still being able to interact with the codebase, even if the container repo is temporarily unavailable, or vice versa.
That said, in a few years I might come around to holding the opposite views again - frankly, both approaches are good and seeing the Gitea Actions project is nice! Though I'll also acknowledge that some might claim that all-in-one solutions are sometimes a bit half-baked, a criticism that I've heard of GitLab in the past (though honestly they're also fine, especially for the more enterprise settings, where you have beefier servers and a few people to manage the install).
This situation is actually a bit more insidious. All these CI/CD features are just a thinly veiled attempt at locking users into the platform. There's not big money to be made selling git hosting, but if you control how the software is built, then you have made yourself a hard dependency. If you look at the starter workflows they provide, they encourage bad practices where your application build is defined in their DSL. Experienced programmers might steer away from such usage, but many novice won't. If you have enough novice adoption, it becomes the norm. So many projects these days cannot even be built locally without a CI service dependency, where instead 99% of the time, all you needed was a simple makefile.
And Chinese author does mean CCP, assuming they live in China they are almost certainly able to be compromised and it is a bad decision to trust them with something as valuable as your whole code base.
With authoritarian nations and their ability to control and steal your projects, you assume guilty until proven innocent. You should require there be a real audit before you trust gitea.
This anti-Chinese hysteria is hilarious to watch from the sidelines, honestly. A few months ago there was a comment on HN by some American whose company was rewriting their frontend when they learned that antd (a React component toolkit) was developed by a Chinese company.
https://github.com/ant-design/ant-design
> A few months ago there was a comment on HN by some American whose company was rewriting their frontend when they learned that antd (a React component toolkit) was developed by a Chinese company.
This is a good move. We're removing Lenovo laptops from our infrastructure here.
Seemed to me like they had a point and it's worth considering following that project [2] instead.
[0] https://gitea-open-letter.coding.social/
[1] https://news.ycombinator.com/item?id=33372471
[2] https://codeberg.org/forgejo/forgejo
There have been a few cases of open source collectives/coops that do what Gitea does but distribute the profits to contributors equally, wonder if any of those have reached sustainability.
In the past months all they have done is rebrand Gitea and some minor fixes, but upstream (gitea) has added a huge number of features and merged tons of valuable pull requests. So are they just going to continuously merge upstream into their fork and do nothing besides that?
The platform, Codeberg might be "well" funded but not to maintain another extra project and develop new features for it.
I think the outrage was a little too big initially. It's a big task to create a git host that needs to compete with Github and the likes and I think it's fair that you want to make some money on the side with that.
Compare these merged PRs:
Forgejo https://codeberg.org/forgejo/forgejo/pulls?q=&type=all&sort=...
Gitea https://github.com/go-gitea/gitea/pulls?q=is%3Apr+is%3Aclose...
That seems completely irrelevant and orthogonal to the outrage though?
Just to clarify, only one maintainer left the project to my knowledge, although a few other contributors did as well. The majority of us remained with the Gitea project.
At this point forgejo is just a soft-fork as well, so there really isn't any reason or hurry to switch (yet) in my opinion.
Though it did stand out that they are migrating stuff from gitea.io to gitea.com, as mentioned in this blog post.
We've had the .com domain for a little while, so now we're starting to consolidate things to it.
Disclaimer: I am a part of the Gitea TOC, and am employed to work on Gitea.
The Forjero commits prove that this is incorrect (they are still busy removing Gitea branding related things from their code). It's going to take a long time until they begin to match the Gitea momentum.
I'd hope so! I am not interested in many of the features being added to Gitea (i.e. the momentum you allude to[1]). I want a light binary I can continue to self-host on a Raspberry Pi Zero that doesn't have Docker installed.
1. I feel Gitea is being positioned as a competitor to GitHub and GitLab - good for them! However, the previous iteration was close to perfect for my needs, albeit not very monetizable. I'm glad it got forked and will be side-grading to Forgejo.
The momentum stalled when the community was plagued recently by toxic behaviour of one of the members who started the fork. He had to step down from the "well-being" team[1], bullied a moderation team member into stepping down[2] and forced him to disclose information from a private chat[3].
Now he is trying to "reboot" the community to erase his previous bad behaviour [4]
Forgejo members are also unhappy about conflicts of interest of this individual [5]
The Forgejo community is stronger than this one individual, so it will succeed.
[1]: https://codeberg.org/forgejo/meta/commit/d822fc3b90f79372023...
[2]: https://codeberg.org/forgejo/meta/issues/176#issuecomment-82...
[3]: https://codeberg.org/forgejo/meta/issues/176#issuecomment-82...
[4]: https://codeberg.org/forgejo/meta/issues/187
[5]: https://codeberg.org/forgejo/meta/pulls/180#issuecomment-843...
The Forgejo folks seem to object to Gitea on the basis that a company took the project over. I think it was that an American company took it over, not that a company took it over. They didn't AGPL forego, they just soft forked and backed the fork with a European organization instead of an American one, Codeberg[1]. Yes, the org is non-profit, but it still smacks as hypocritical.
I'll be sticking with Gitea for the foreseeable future.
1: https://codeberg.org/
Straining to assume good faith here but this seems very likely to be wilful misinfo - particularly given the emphasis. The reasons for the fork are very clearly stated in the lettter linked in the comment you're replying to: it's about community decision-making procedures (which have been removed during the incorporation). It's also about profit: the US corp is for-profit.
Secondly, not only are Codeberg a non-profit, they also adopted the project after the fork. That wasn't a part of the original letter nor discussion. They don't control the project (see aforementioned objections on the basis of democratic input) - they're a host & benefactor.
A quick clarification here, the new TOC is comprised of three company members and three community members, with community members having a slight advantage should there be a split vote on anything.
A small clarification, Gitea Ltd. which owns the trademark and domain is (apparently) based in China.
https://forum.forgefriends.org/t/gitea-ltd-company/917/5
No, Gitea Ltd is a new _Hong Kong_ for-profit company. No American companies are involved in any of this whatsoever.
The Gitea head honcho claims to be in Shanghai, China: https://gitea.com/lunny
> not that a company took it over.
No, the Forgejo folks were angry that the previously community-run project was taken into ownership of a for-profit company, without any notice, and against previous promises: https://gitea-open-letter.coding.social
> They didn't AGPL forego
Uh, they CAN'T relicense it to AGPL or anything else. The Gitea authors and contributors still hold the copyright on the code, which is MIT-licensed.
Could someone post a link to the decision?
I think, this seems to be the discussion everyone is talking about
https://forgejo.org/2023-02-27-forgejo-actions/
"This is a custom fork of nektos/act, for the purpose of serving act_runner.
It cannot be used as command line tool anymore, but only as a library.
It's a soft fork, which means that it will tracking the latest release of nektos/act."
Now I worry even more about everyone maintaining forks of everything rather than doing original development.
I wonder what differences there are between Gitea's and Forgejo's forks, and also why they couldn't work with upstream.
So far everything about it has been excellent, and it's only getting better!
Are you working on anything publicly available? I'm looking for something new to play :)
Disclaimer: I am a part of the Gitea TOC, and am employed to work on Gitea.
I don't use Gitea, but if I were to start today would there be a proper reason to avoid Gitea?
Gitea will remain fully open source with no tiers.
The community TOC also has advantages in any such voting where something may negatively affect the OS project, although as you mentioned that hasn't happened yet, and I don't expect it will.
Both of them will give you nearly the same experience, and they are a soft fork so all Gitea changes will be available.
I'm biased as a community member of the Gitea TOC, so I'd of course recommend Gitea.
A lot of comments about "Forgejo". In short: meh. Not a big deal[2]. I'll be sticking with Gitea.
1: https://github.com/go-gitea/gitea/issues/14186
2: https://news.ycombinator.com/item?id=35233168
https://forgejo.org/static/forgejo.mp4
Not a lot of dog-fooding going on over there.
https://github.com/go-gitea/gitea/issues/1029
The main repo, however, has a lot of issues/prs/etc metadata and so migrating is a bit harder.
This is horrible!
While reverse proxy auth should be disabled by default, this is critical. This breaking change makes gitea unsuitable for me going forward.
Reverse proxy auth is perfectly secure when correctly setup and is sensible in many configurations.
BTW, a colleague of mine told me that GitHub Actions wasn't supposed to be a CI/CD alternative at the time when it was released. I couldn't find any note on that online. Is it true?
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 it for enhanced integration with Gitea, so you could use woodpecker but have the experience be next to your code.
Disclaimer: I am listed as a maintainer of Woodpecker. I am a also part of the Gitea TOC, and am employed to work on Gitea
Not sure what you mean by that, what was it supposed to be then?
edit: looks like Forgejo is already talking about Actions support https://forgejo.org/2023-02-27-forgejo-actions/