[HN Gopher] Gitea - a painless self-hosted Git service
___________________________________________________________________
Gitea - a painless self-hosted Git service
Author : thunderbong
Score : 273 points
Date : 2022-06-05 08:03 UTC (14 hours ago)
(HTM) web link (gitea.io)
(TXT) w3m dump (gitea.io)
| rapnie wrote:
| Most exciting that they are working on federation support that'll
| tie individual self-hosted servers together.
|
| https://nlnet.nl/project/Gitea/
| rapnie wrote:
| Other projects mentioned are:
|
| https://forgeflux.org
|
| https://forgefriends.org
|
| https://forgefed.peers.community
| synergy20 wrote:
| been using it for 4+ years, no complains and it keeps getting
| better. each upgrade is super simple: just stop the service,
| replace that one single binary, and start the service.
| bnajdecki wrote:
| Using it for more than a year - It's an awesome project. Can
| easily work on the cheapest DO VPS.
| thealistra wrote:
| The site tbh looks awfully similar to github. Can this be like a
| reason for a lawsuit, if github had a bad day?
| secwang wrote:
| Fossil is better for small project
| LinuxBender wrote:
| Adding link [1] for reference.
|
| [1] - https://fossil-scm.org/home/doc/trunk/www/index.wiki
| runeks wrote:
| Why?
| thunderbong wrote:
| Single binary. Cross platform. Runs with it's own server with
| web interface. Has issue tracking, wiki, chat.
|
| Happy user of fossil since over 10 years now, both in
| individual projects and teams' projects.
|
| For me, unlike git, fossil just gets out of the way and let's
| me focus on delivering. Doesn't have a whole bunch of arcane
| commands.
|
| https://andreiclinciu.net/blog/why-im-using-fossil-scm-
| inste...
| StevePerkins wrote:
| That's not a Git web interface, that's a completely different
| source control system altogether!
|
| And from a quick bit of web searching, it looks like most IDE's
| out there either lack a plugin for fossil, or else have a
| plugin that's outdated and doesn't keep up with the current
| version of the IDE.
|
| I realize that all of these "I Like X!" silly HN threads invite
| a lot of "I Like Y!" silly replies, but there sure are a lot of
| caveats on "better" here. You could make a much stronger case
| for recommending Subversion or CVS, lol.
| secwang wrote:
| yes, thank you.But light and self Hosted version control,I
| have to recommand fossil.Git is not gods,we can blame it and
| recommand other more better software for special case.
| rascul wrote:
| How is it better?
| thunderbong wrote:
| Why You Should Use Fossil - https://fossil-
| scm.org/home/doc/trunk/www/whyusefossil.wiki
| holografix wrote:
| I found the Auth bit a bit difficult to parse. I wanted to used
| Firebase for it but didn't quite know how. How are people
| handling user registration and SSO?
| igtztorrero wrote:
| I use GitLab CE since 2012, and checking
| https://docs.gitea.io/en-us/comparison/ gitea vs gitlab the main
| difference is: "Low resource usage (RAM/CPU)"
|
| I see why: Gitea is 75%-Golang, 13%-HandleBarsJs GitLab is
| 85%-Ruby 12%-HTML
|
| Never have a problem with Gitlab, but is RUBY is slow and cpu
| demand
|
| I will try it !
| jlturner wrote:
| I've been running local Gitea for about 4 years. It works great,
| no complaints here. I mirror my GitHub repos (and sensitive repos
| I don't want to trust on GitHub) and back up the hard drives with
| BackBlaze.
| mac-chaffee wrote:
| I've been happy with Gitea. It's very fast, and upgrades cannot
| be simpler. Just download the new binary and start it. The
| migrations run automatically.
|
| If you need a git hosting service but "hosting git" isn't your
| day job, then the alternatives are way more complex than
| necessary IMO.
| bioemerl wrote:
| It would be generally be a good idea to migrate away from this to
| something else, I use gitbucket, and it works very well for me.
|
| Yes it is an open source project, but the entire team that works
| on it is based out in China, and that's really not something you
| want to play games with.
| DethNinja wrote:
| Do you got any proof about "entire team" being based in China?
|
| It looks like they got developers from bunch of other locations
| at least according to their Github activity.
| bioemerl wrote:
| If it's the entire team or not doesn't really matter, what
| matters is is that the locus of control, the people who
| really own the project and commit most of the changes are all
| based in China.
|
| But you are correct, they do get commits from outside of the
| country
| matsemann wrote:
| In that vein, as a European I'm generally more afraid of US.
| How they can force anyone to give up my secrets. Or the power
| of Google, MS, Facebook to screw me over.
| bioemerl wrote:
| The alternative project I mentioned is actually mostly
| developed by Japanese developers.
| Zababa wrote:
| Has there been any issues because of that, or is this just
| speculation on your part? The codebase is open source so it's
| not like they can hide anything.
| roastedpeacock wrote:
| I am no Sinophobe but I think the pragmatic concern is by
| being under P.R.C jurisdiction 'certain parties' could either
| force abandonment of the project by (some of) the original
| team or compel certain code changes that may not be in the
| users interest.
|
| No offense to anyone and do not want to imply anything
| nefarious is about but from what I remember Gogs was even
| worse in that only a single maintainer inside P.R.C had merge
| access to the main branch. Also a concern because I might
| remember something about known vulnerabilities having been
| outstanding on the issue-tracker when the maintainer was
| busy.
| bioemerl wrote:
| It's not so much about the issues, but the potential for
| issues down the line.
|
| For tools like this the aim is always to lay low and expand
| to reach as far as possible, then once you have a lot of
| control and trust you can abuse it, often you can abuse it
| without much loss, because once you have institutional
| momentum it's very hard to screw it up.
|
| You can't operate on If there's a history of abuse of power,
| only if there is an incentive. I believe there's a very
| strong incentive in this case.
| Zababa wrote:
| I don't really see how can an open source project that you
| can self host be abused. Do you have any example of that
| happening?
| bioemerl wrote:
| All you need to do is sneak in something in an update
| that gives people access to your server, or creates a
| vulnerability that allows them to get access.
|
| The fact that itself hosted is actually a really huge
| concern, because this thing is sitting on your local
| network with no firewall between it and everything else
| that you run.
|
| It takes very little to put a vulnerability in a piece of
| code, and unless you have a person combing every commit
| with a fine tooth comb, even the fact that it's open
| source cannot prevent that.
|
| No single security measure is bulletproof. Being open
| source does not counteract the misaligned incentives.
| [deleted]
| rascul wrote:
| > Yes it is an open source project, but the entire team that
| works on it is based out in China, and that's really not
| something you want to play games with.
|
| Maybe you could expand on why this is an issue.
| bioemerl wrote:
| China is a country that has been well well known for theft of
| intellectual property for a couple of decades now, and when
| the majority of the people developing the project live inside
| of the borders of China their state has an incredible ability
| to control the direction of the project and sneak in bad
| changes over time should they want to.
|
| The fact that it's open source helps a little bit, but I do
| not believe they number of eyes on the project is enough that
| they couldn't sneak something through if they wanted to. This
| isn't Linux with worldwide attention, it's a relative niche.
| nanomonkey wrote:
| I've enjoyed using git-ssb
| (https://scuttlebot.io/apis/community/git-ssb.html), which allows
| me to save and share git repos using the scuttlebutt gossip
| protocol. Makes for a nice decentralized solution where I can
| back up between my machines, and those that I'm working on a
| project with.
|
| The only problem that I've found is that my github repo now shows
| very little activity which make job hunting harder.
| jamal-kumar wrote:
| I have some personal projects on my own public git server that
| hardly anyone knows about but I still have a second remote for
| that stuff which goes on my github for the jobs.
| hericium wrote:
| Is it possible to hide users listing[1] on Gitea via
| configuration?
|
| On Gogs it's not configurable and to stop publishing names of all
| users, including admin account username, it's necessary to either
| close down the whole service (disable public view of all repos
| and disable signup) or block certain addresses on proxy level.
|
| [1] https://gitea.com/explore/users
| dancemethis wrote:
| It's almost perfect. A small fork removing Discord things makes
| it effectively so.
| bdeshi wrote:
| what discord things?
| sli wrote:
| It supports Discord webhooks[0].
|
| [0]: https://github.com/go-
| gitea/gitea/blob/main/services/webhook...
| smcl wrote:
| Is it possible to not use the Discord things?
| roastedpeacock wrote:
| No fan of Discord but from what I remember the functionality
| is opt-in and if the webhook is not configured it does
| nothing.
|
| Among all the possible things to get worked-up about this
| seems like nothing (unless you are purist that considers
| including optional functionality to interface with a
| proprietary-service to be harmful).
| waplot wrote:
| They're just webhooks, not sure what the issue is (?)
| xbeta wrote:
| One of my previous companies use their self-hosted Gitea. That's
| all good and stuff, but they don't have a dedicated DevOps
| person, so we actually have to spend extra maintenance on it.
|
| Moreover, we were going through SOC-2 auditing at that time and
| it is much easier to just store our source code in one of the
| SaaS option like Github/GitLab/Bitbucket for our auditors to
| check without having me to screenshot everything for them.
| rascul wrote:
| I find Gitea to be great. Also there is a curated list of awesome
| projects related to Gitea:
|
| https://gitea.com/gitea/awesome-gitea
| trentthethief wrote:
| Cgit is even more light weight and secure.
| LinuxBender wrote:
| And it appears Arch has a nice document regarding the
| installation [1]
|
| [1] - https://wiki.archlinux.org/title/cgit
| russianxol wrote:
| jamal-kumar wrote:
| I'm a huge fan! Written by Jason Donenfeld and company so you
| know it's solid code, too.
|
| https://git.zx2c4.com/cgit/about/
| chappi42 wrote:
| FWIW I prefer gogs (from the original developer).
| keb_ wrote:
| Why do you prefer gogs? Never tried either, so curious.
| chappi42 wrote:
| In the beginning after the fork, gitea added features which I
| didn't need. Nothing against gitea just thought I'd also
| mention gogs, which hummed along here fine and if possible I
| prefer the code from the original author. (Edit, mmh, not
| always true, I use neovim...)
| jamal-kumar wrote:
| At a company I worked at, for security reasons we used gogs.
| Boss didn't want some random NPM-downloaded javascript
| anywhere near our source code, which was something which
| handled enormous piles of money. Gogs doesn't bother with any
| nodejs at all.
|
| Personally I like even MORE basic than gogs or gitea and use
| this at my own company:
|
| https://git.zx2c4.com/cgit/about/
|
| It's like a single binary packaged up, and a few lines on
| openbsd httpd to get it running. Pretty sweet!
| ironmagma wrote:
| I'll go against the grain and say, Gitea is good but could use a
| lot of improvement. We use it at my company (startup) and find
| there are issues with migrations (up but no down), nonstandard
| web framework (go-macaron), and far too much logic implemented in
| go templates. There are also some strange issues with how errors
| are reported. Go is a fine language, but Gitea isn't a great Go
| codebase.
|
| Of course, we/I understand open source software isn't perfect and
| such. That isn't my point, I'm just saying that Gitea could use a
| complete rewrite, ideally using NextJS (if SSR is that important)
| or moving most if not all view logic into the client side,
| ditching go-macaron and xorm for something more widely used,
| relying less heavily on go templates, and doing error handling a
| bit better.
|
| That said, Gitea does have a good excuse which is that it
| inherited many of these things from Gogs, from which it was
| forked.
| muhehe wrote:
| I'll go and say a really _don 't like_ arrogant comments like
| yours. Shitting on someone's work you're using for free by
| recommending complete rewrite in technologies you currently
| like is absurd. Less used framework - so what. Logic in
| templates - yeah not great but still, so what? Etc... Doesn't
| really bother anyone using it.
| ironmagma wrote:
| I would also add that I don't even like NextJS. I'm
| recommending it because it's a better engineering choice. I'd
| much rather see it rewritten in Rust, but that's irrelevant.
| muhehe wrote:
| I really wonder what makes you think nextjs is better
| engineering choice.
|
| (I really do want to know, I don't mean this question in
| any negative way.)
| ironmagma wrote:
| SSR is "fine", but it doesn't need to be this painful.
| Here's an example buggy piece of code:
| {{range $i, $file := .Diff.Files}} <div>
| {{ if $file.IsSpecialFile }} <div>Special
| file ({{$file.name}}) {{ end }} </div>
| {{end}}
|
| Because of the missing </div>, instead of a list of
| files, it produces a file listing inside of another file
| listing inside of another, etc. That's just something
| you'd never be able to accidentally do in NextJS, or
| anything that uses JSX-like structure.
|
| Then there are clerical things like where to put styles
| and presentation logic. Gitea uses a mix between jQuery
| and Vue, with CSS rules sprinkled in randomly. The result
| is that by looking at the template and the class names on
| each element, you have no idea whether a class name or ID
| is going to have significance to jQuery, CSS, or if it's
| just dead code. Something like styled-components, and use
| of a single stack (Next as opposed to jQuery+Vue)
| eliminates the fear and clerical aspect of development.
| skrtskrt wrote:
| Logic in templates is just a classic lack of separation of
| concerns that makes a project into a ball of mud as it grows
| muhehe wrote:
| Does it directly affect users?
| ironmagma wrote:
| No, but it indirectly affects users.
| kanonieer wrote:
| It's not just arrogance, it's called being a "modern JS
| developer". The bubble some of these people are living in is
| so rigid, they can't simply accept when someone does things
| differently. Some quotes from the parent are as follows,
| accompanied with some sarcasm on my end:
|
| > nonstandard web framework (go-macaron)...
|
| The "standard" is React and Vercel offerings. Get with the
| times.
|
| > ditching go-macaron and xorm for something more widely
| used...
|
| You're only supposed to use libraries that are #1 popularity
| in their respective category, few weeks of no commits means
| the library is dead.
|
| > I would also add that I don't even like NextJS. I'm
| recommending it because it's a better engineering choice...
|
| Yes, you read that right. This is the advice for Gitea:
| Github, Gitlab, SourceHut all used server-side templates, so
| much so that latter two are quite useful even when JS is
| disabled- but the "better engineering choice" (citations
| sorely needed) is NextJS.
| ironmagma wrote:
| > few weeks of no commits means the library is dead.
|
| Xorm is so old and disused, it's been absorbed into Gitea
| and the Github repo is archived as read-only. You get much
| better capability out of something that's widely used,
| that's it. I don't care at all about how "modern" something
| is, if you can't roll back a migration because of your ORM
| then you have a nonideal ORM.
|
| > The "standard" is React and Vercel offerings
|
| No, I was thinking Gin or Buffalo. Something that a lot of
| people use and that's seeing a lot of love, you know... a
| standard.
|
| > they can't simply accept when someone does things
| differently.
|
| Yea, that's why I continue to accept Gitea as a good piece
| of software. Only people who cannot accept software
| packages as they are go out, call them "good", and try to
| get people to understand how it can become even better.
| ironmagma wrote:
| There's nothing arrogant in my comment. Like I said, Gitea is
| good. Like all other software, iterations improve quality,
| and I'm just saying it's time for the next iteration. I
| probably would have written Gitea the exact same way if I
| were in the developers' shoes, but that doesn't mean a
| rewrite wouldn't still be in order.
|
| As for the so what, I think the answer is just that things
| can be better, so if someone is out there reading this thread
| who has some time, they can see this and know what kind of
| improvements can be made.
| muhehe wrote:
| Suggesting improvements is ok. Recommending complete
| rewrite in different stack and technologies is not
| constructive critique imo.
| ironmagma wrote:
| Elsewhere on the Internet, someone posted:
|
| > If it ain't broke don't fix it? Or is there some
| specific shortcomming that might justify a rewrite?
|
| I'm answering that question. The information is out
| there, so if people want to ignore it that's beyond my
| mandate. But this is still constructive since someone out
| there wanting to rewrite Gitea will want to know what the
| pain points are before they do so.
| Zababa wrote:
| I understand how migrations issues could be a problem, but how
| is the nonstandard web framework and the logic in the templates
| a problem as a user? Maybe it makes it harder for you to
| contribute to the project (and probaably for other people),
| thus slowing down the rate of improvement? Maybe other
| framework have better performance? Not denying your experience,
| just curious about the consequences of stuff like go-macaron.
| ironmagma wrote:
| Makes bugs harder to fix/diagnose and new features harder to
| implement. Yes, there is some UX and performance cost for
| certain actions if they require a roundtrip to the server.
| That isn't my main concern, it's just the speed of
| development.
|
| For migrations, if a migration fails, you have no way of
| rolling it back because they only go up and not down. This is
| just a specific instance of the problem of having less
| popular dependencies -- the bug fixes and new features are
| less plentiful because there's not as wide of a community.
| That applies to xorm and go-macaron.
| solar-ice wrote:
| Can you show an example of excessive logic in templates? My
| experience of Go templates is that they're practically
| impossible to implement any interesting logic in, so that's
| certainly interesting.
| ironmagma wrote:
| https://github.com/go-
| gitea/gitea/blob/368baf9e77606e5de8bbc...
|
| Here's a good sample file. The cyclomatic complexity is
| through the roof: note the variable assignments, function
| calls, string concatenation, large number of `if`/`else if`s,
| nested conditional expressions (line 254). I don't even want
| to know how many permutations of this page are possible...
| neatze wrote:
| I was compelled to learn GO because Gitea, running it docker and
| on commit Gitea triggers tasks on multiple Mini PCs (wrote my own
| simple CI).
| malteg wrote:
| Try drone?
| Loic wrote:
| Or Woodpecker[0], a fork of Drone keeping the Apache 2
| license.
|
| [0]: https://woodpecker-ci.org/
| capableweb wrote:
| Woodpecker is what Codeberg (Gitea deployment) is using and
| it works wonderfully!
|
| Here is an example pipeline I use to build and deploy
| Ditzes (my offline/desktop HN client):
|
| https://codeberg.org/ditzes/ditzes/src/commit/410486175a2de
| a...
| tomohawk wrote:
| We did comparisons between self hosted gitlab and gitea.
|
| gitea was considerably easier to set up, and much more
| bulletproof. gitea was much lighter on resources.
|
| We had a use case to be able to mirror thousands of repos. gitlab
| would fall flat on its face. gitea had no issues.
|
| We turned this over to corporate, and they chose gitlab. gitlab
| had great sales people.
| chrismorgan wrote:
| I don't feel that "Git service" is quite doing it justice. If it
| were just a Git service, I don't think it'd have the social
| features: repository namespacing, user accounts (at least to the
| extent it has them), issue tracking, pull requests, release
| management, wiki, watching/starring/forking...
|
| Now as it happens, I actively _don't want_ any of that stuff for
| something I'm hosting for myself for my own projects only. I
| pretty much just want the parts you'd get in gitweb or cgit, but
| done better (since neither of those is very good; I run gitweb
| because I wasn't impressed with either, but gitweb was easier to
| patch into a more acceptable shape). Is Gitea capable of being
| pared down to just this? Is there anything else that fills this
| niche?
| lapser wrote:
| Sure Gitea does a bit too much for a single individual, but you
| don't have to use the additional features. Honestly, the UX of
| gitweb is pretty bad so even if Gitea has too much, it's still
| better than gitweb. Who knows, maybe someone will clone a Gitea
| and rip out all the social features from it.
| lmas wrote:
| I've been thinking of making Yet Another Git Repo Browser(tm)
| from scratch these last couple of years, with features I've
| been missing in gitweb and with a cleaner/more familiar UI.
| Maybe it's time to revive that old prototype.
|
| What issues did you have with gitweb? And what stuff did you
| patch up?
| Tmpod wrote:
| You could try setup just a git.sr.ht instance, I suppose. Dunno
| if it is what you're looking for, but it might be worth
| checking out.
| chrismorgan wrote:
| As regards _features_ , git.sr.ht is certainly lighter than
| Gitea, but still suffers from various of the same problems
| because it's designed to run the show with social operation,
| rather than just doing read-only publication of repositories
| that it finds at such-and-such a location. It doesn't have
| _as_ much extraneous and undesirable functionality (e.g. no
| issue tracking), but when setting it up requires PostgreSQL
| and Redis (which latter I think you _may_ be able to skip,
| but it's hard-required in the systemd units I see) and
| more... yeah, this is not what I'm looking for.
| Operationally, Gitea is considerably lighter than git.sr.ht,
| as you can get it going with _only_ Git and SQLite installed.
| pvinis wrote:
| im trying to remember one. I used it and I think you will like
| it. but it's been a while and i am forgetful!
|
| it was something short, the url too. it was sh or st something.
|
| can anyone get which one I mean?
|
| edit: YES! it's sr.ht. thanks, commenter below this :)
| KronisLV wrote:
| I recently moved over from self-hosting GitLab to instead having
| Gitea, Nexus and Drone, because the burden of keeping GitLab up
| to date was cumbersome, given how it's such a large and
| complicated software package.
|
| I wrote about it in my blog post "Goodbye GitLab; Hello Gitea,
| Nexus and Drone": https://blog.kronis.dev/articles/goodbye-
| gitlab-hello-gitea-...
|
| That said, I still find the UI of GitHub and GitLab to be a bit
| better than Gitea's (the whole organizations/groups navigation
| feels better), though Gitea is immeasurably more performant when
| compared to GitLab, especially when the available hardware
| resources are limited - in the case of 4 GB of RAM being all that
| I could afford, it's the difference between a really snappy and
| annoyingly laggy UI.
|
| Admittedly, now it's Nexus that loves eating my resources, though
| for the most part having software like it for managing most of my
| container images and other packages is pretty cool and
| worthwhile, though one might also want to explore the
| alternatives, such as Artifactory or something else.
|
| Also, personally I find Drone to be a bit less capable than
| GitLab CI and its documentation isn't quite as good in comparison
| - though that's a given, since it's an external tool developed by
| another company. Though I guess even Jenkins would also be a
| viable alternative (despite it having certain issues with plugin
| stability etc.), or many other CI tools, given that Gitea is
| actually decently supported!
|
| In summary, even if there still are a few challenges here and
| there, the whole setup is a lovely way to self-host your own
| projects and everything around them in a cost effective manner
| and whilst also staying in control over your own data. Gitea is
| an important part of this and overall I'm really glad that we
| have cool software like it nowadays!
|
| At the same time, I'm more than happy to use GitLab or something
| like it at work, as long as keeping it working nicely, up to date
| (and paying for the servers) is someone else's responsibility.
| bluehatbrit wrote:
| Mind if I ask how you're hosting this setup, are you using
| something like k8s or swarm? If so how are you handling
| persistence, just normal volumes? I imagine if you were to lose
| data, that'd be pretty bad.
| KronisLV wrote:
| Currently using Docker Swarm with bind mounts instead of
| volumes, because they're a bit easier to work with, backup-
| wise.
|
| Infrastructure wise, there are a few VPSes from a local
| provider (https://www.time4vps.com/?affid=5294 affiliate
| link), though I've also used DigitalOcean, Hetzner, Scaleway
| and others in the past, AWS, GCP and Azure would work as
| well, though would be much more expensive. For executing CI
| tasks and backing up the data, i have a few servers on my
| desk (though regular towers with passive cooling, instead of
| the rack mounted kind), since those are more cost effective,
| especially storage wise.
|
| The actual files are backed up with BackupPC over the network
| automatically, at a set interval, to another server:
| https://backuppc.github.io/backuppc/ Then, of course, the
| backup server data is occasionally sent to another server in
| my local network, just to spread it around more, in case of
| disk failures or one of the servers shorting out.
|
| Admittedly, it's a lot like using regular rsync with cron,
| although the benefits of BackupPC are being able to really
| easily restore files, as well as having incremental backups
| with compression.
|
| It is a bit rudimentary as far as handling data goes, but
| sometimes that's all that you need:
| https://blog.kronis.dev/tutorials/simple-ways-to-do-backups
|
| Alternatively, one might also achieve the same result with
| something like Bacula, Kubernetes with either hostPath or
| maybe even just a NFS mount. Other folks might prefer
| something like GlusterFS or a similar distributed storage
| solution, or something like Longhorn for Kubernetes in
| particular.
| mkesper wrote:
| Maintaining Jenkins and its gazillions of plugins is such a
| hassle I'd never consider it for a new project.
| [deleted]
| jonnycomputer wrote:
| I wanted to self-host a git server, and because I use gitlab at
| work, that was my first choice. But the system requirements for
| gitlab were too heavy for the linode I was running, so I went
| with gitea. Linode also had a handy install-script to set
| everything up painlessly.
|
| I concur with your overall assessment.
| qbasic_forever wrote:
| You'll probably be happy to see the 1.17 dev version of gitea
| (which should be the next major release) actually has an
| artifact repository built in and it can even host docker
| images: https://docs.gitea.io/en-us/packages/overview/ You have
| to build the branch yourself right now though, despite being in
| the docs it's not in the release downloads yet. You might be
| able to get rid of nexus and just use this built in registry.
| KronisLV wrote:
| That's actually pretty cool to hear!
|
| Though a problem that I ran into with GitLab Registry was
| that sometimes the Docker image cleanup wasn't done properly
| and old layers kept lingering around and eating a lot of
| space. I sort of fixed it with some cleanup scripts and the
| occasional manual actions, but it still was a bit problematic
| since running out of space was a very real risk.
|
| Nexus does appear to have similar issues, should you use it
| as an intermediary for CI image builds (e.g. tag it with
| branch-date and tell your cluster to redeploy the image), but
| at least it has instructions for cleaning it up that work
| most of the time:
| https://help.sonatype.com/repomanager3/nexus-repository-
| admi...
|
| Personally, I think that using the same software package for
| storing build artifacts and the source code itself is a bit
| risky, but maybe Gitea will be able to tackle those
| challenges with no significant issues!
| jonnycomputer wrote:
| I just discovered that the latest gitea supports package
| repositories. I'd like to see something that works for R
| packages without too much hassle.
| Inversechi wrote:
| By Drone do you mean the `0.8` open source version? If you've
| not tried Woodpecker it built upon the `0.8` code and added
| lots of nice functionality, has better documentation, and is in
| active development.
|
| https://woodpecker-ci.org/
| KronisLV wrote:
| I mean the currently available 2.X set of versions:
| https://docs.drone.io/server/provider/gitea/
|
| Its source code is also available on GitHub:
| https://github.com/harness/drone/releases
|
| Of course, the point about their license is a good one, which
| definitely has some limitations on what you can do with it:
| https://github.com/harness/drone/blob/master/LICENSE (I wish
| I earnt 5 million $ and this would be a problem I'd have to
| think about).
|
| Thanks for bringing up Woodpecker, though, it also seems like
| a nice project and the two CI solutions haven't diverged far
| enough for migrating over from one to another to be too
| problematic, should that become relevant in the future:
| https://github.com/woodpecker-ci/woodpecker
|
| Of course, as I said, some folks might also prefer something
| like Jenkins or another CI solution. I'm yet to explore most
| of the packages out there!
| InfamousRece wrote:
| Last time I tried Gitea, it was surprisingly difficult to migrate
| existing git repos. I hope they made it easier.
| nik736 wrote:
| I am using Gitea + Drone for several years now and couldn't be
| happier. Stable, fast and it justs works without consuming a
| shitload of RAM.
| lapser wrote:
| Woodpecker CI is a fully open source fork of Drone CI. Drone
| changed their license so they forked it.
| dividedbyzero wrote:
| What did they change it to?
| generichuman wrote:
| It seems to be licensed under Apache 2.0 (for community
| edition) + some custom commercial license (for enterprise
| edition). See here:
| https://github.com/harness/drone/blob/master/LICENSE
| IshKebab wrote:
| How do those Docker-based CI systems support Windows and Mac
| builders? Aren't you constrained to just Linux? Seems like
| quite a crippling constraint in a huge number of situations.
| rapnie wrote:
| Yes, they integrated it with Codeberg.org also running Gitea.
| abdusco wrote:
| One great feature of Gitea is that you can create private repos
| without using the UI/CLI by adding a git remote.
| git remote add origin https://my.gitea/user/new_repo git
| push # user/new_repo is created as a private repo
|
| Super cool. Does Github have such a feature?
| unqueued wrote:
| For GitHub, using the hub[1] client, you can simply do:
| hub create -p
|
| That will create a new private repo, matching the name of your
| repository.
|
| What I will often do if I want to instantly mirror something to
| github: hub create -p --remote-name=github
|
| Which will create a new remote with that name. Otherwise origin
| will be used, which can conflict if you already have an origin
| remote.
|
| It is also less typing.
|
| [1]: https://github.com/github/hub
| phpisthebest wrote:
| I dislike organizations that take open source things like
| git, and then extend them to add features making them
| propriety work flow lock in making it hard to move to a new
| platform
|
| Another company was famous for this, they used to call it
| Embrace, Extend, Extinguish
| unqueued wrote:
| Well, with the hub cli, it is just using GitHub's public
| API. I don't think it is doing anything proprietary.
| rglullis wrote:
| > I don't think it is doing anything proprietary.
|
| Does github provide the code of their servers that
| implements the API? Can you self-host it? If not, then it
| is pretty proprietary.
| gurjeet wrote:
| Notably, SourceHut has this feature.
| INTPenis wrote:
| Not sure about Github but Gitlab does. It just creates a new
| repo under your account when you push to a non-existing one.
| Seems like a very basic feature to me.
|
| And the default setting happens to be private.
| madacol wrote:
| Just tested, github fails
| filmgirlcw wrote:
| Not sure if doing it that way will create a private repo or not
| (at the airport and I can't check), but you can use the GitHub
| CLI to do it. I'm a huge fan of the CLI, but obviously being
| able to do it without that is nice.
|
| https://docs.github.com/en/get-started/quickstart/create-a-r...
| klik99 wrote:
| It appears as if the main repo along with issue tracking and pull
| requests is hosted on GitHub: https://github.com/go-gitea/gitea -
| At least it looks that way, are issues/pull requests mirrored
| across to GitHub?
|
| I have to admit, if the GitHub repo is the main source for
| issues/PRs, it's a bit of a yellow flag that they're not
| dogfooding it.
|
| That being said - if I didn't need easy CI support I'd probably
| be using Gitea instead of GitLab CE - GitLab CE is great but it's
| a resource hog and feels like it's getting slower over the years.
| tylersmith wrote:
| I was curious about this so I searched and found that they
| started using Github before all the necessary features were
| ready in Gitea, and they are in the process of moving. The only
| thing left now to do is actually implement a feature to import
| content from Github.
|
| Here is an issue tracking the migration: https://github.com/go-
| gitea/gitea/issues/1029
| kayson wrote:
| I don't think it's a yellow flag. It's hard enough to get
| contributors for FOSS as it is. Adding the additional hurdle of
| creating a new account would be counterproductive. Everyone
| already has a Github account so it's much easier to host it
| there.
|
| What they really need to do first is copy Gitlab and add
| support for logging in with Github. Then they could move their
| repo to gitea without locking out a bunch of contributors (or
| keep a copy on github and mirror issues/PRs)
|
| Edit: looks like you already can login with github and they're
| working on migrating their repos to gitea!
| 2Gkashmiri wrote:
| is there a way to sync gitea/gitlab issues to github? i
| contribute to a project that is on gitlab but there is no
| discoverability. my idea was, if we had a mirror on github,
| at least people could look at issues, suggest fixes without
| having them to login to gitlab.
| kayson wrote:
| I know gitea can mirror a github repo, not sure about
| issues or PRs though.
|
| If you're using gitlab or gitea you should be able to allow
| people to login with github accounts. I used that to raise
| issues about borgmatic[1] and it was very painless. I
| believe it's also mirrored on github but issues aren't
| enabled. Not sure how the maintainer set it up.
|
| [1] https://projects.torsion.org/borgmatic-
| collective/borgmatic
| 3np wrote:
| From an effort-cost-to-performance perspective, Gitea (or
| equivalent) scores very high if you're considering software to
| self-host.
|
| Practically infinite private repos, privacy, automate/customize
| all you want.
| kburman wrote:
| I wish this doesn't become a tool for CCP.
| shp0ngle wrote:
| For a certain definition of "painless".
|
| edit: to clarify. It's fine for a one man show or a small
| company. Once you get bigger, you start hitting the various
| issues quite often, and wish for github again.
| jasonjayr wrote:
| It can also serve as an OIDC IdP[1], which makes it handy to be
| the linchpin for a bunch of developer services with SSO.
|
| 1: https://docs.gitea.io/en-us/oauth2-provider/
| Loic wrote:
| You get access to the organizations in which the user is, which
| is _really nice_ to provide access to other company services
| based on this information.
|
| A small example, we create users for our customers in gitea and
| they are only part of the "customer" organization. This
| automatically get them access to the "customer" worklog as they
| access the customer area. So gitea is for us the central
| identity management.
| grawp wrote:
| I sorely lack subscriptions/watches managment in Gitea.
|
| I'd like to be able to get a list what i'm watching and filter it
| on repo, author, type (issue/pr), and reason like I very often do
| in github.
|
| There is also no session managment accessible from user side :(
| antaviana wrote:
| Can Gitea be configured behind an AWS Load Balancer? I'd like to
| have the ALB to do OIDC authentication with Azure AD, and also
| take care of the SSL offloading (so that we can use ACM
| certificates).
| lapser wrote:
| Considering codeberg.org is a productionized deployment of
| Gitea, I'm guessing deploying a HA version is possible, and you
| can bet that an LB can be put in front of it. As for SSO, I'm
| not sure if Azure AD is supported, but some SSO configurations
| are supported directly in Gitea[0].
|
| [0] https://docs.gitea.io/en-us/authentication/
| zxcvbn4038 wrote:
| I've been using gitea for a number of years - before GitHub
| started letting people have private repos for free it was about
| the only option for a self hosted private repo with a GUI. It's
| written in Go which makes it very convenient to run from a usb
| stick. It also has a feature to mirror other repos and I use that
| to keep local copies of projects I follow - and has saved me a
| couple times when the project authors decided to delete their
| repos or YouTube decided to not host them. Today I use gitea to
| host my private development server as a Tor hidden service which
| makes it easily accessible from almost anywhere - though many
| major hotels chains will ban your MAC address locally if they see
| you connecting to Tor servers, but never had issues while at an
| AirBNB which is where I spend most of my time these days.
| mr90210 wrote:
| Was Gitlab around?
| Macha wrote:
| Timeline:
|
| 2008: Github launched
|
| 2008: Bitbucket launched
|
| 2010: Atlassian purchases bitbucket, makes private repos free
|
| 2011: Gitlab launched
|
| 2014: Gogs (Gitea's predecessor) first public release
|
| 2016: Gitea forks from Gogs
|
| So at the very least, bitbucket was established and gitlab
| was around
| snorlaxle wrote:
| And even before Github, there was Trac
| [https://en.wikipedia.org/wiki/Trac]
| app4soft wrote:
| I'm not sure when Git support was initially added to
| Trac, but TracGit 1.0 released in 2012.[0]
|
| [0] https://trac.edgewall.org/wiki/TracGit
| sam_bristow wrote:
| Nice timeline. One thing to point out though is Bitbucket
| only supported Mercurial up until October 2011.
| jonnycomputer wrote:
| Gitlab is great, but it also is pretty resource hungry. I
| opted for Gitea for that reason, so it would be viable on the
| cheapest Linode server option, and I've mostly been satisfied
| with it, thus far.
| zxcvbn4038 wrote:
| Same, there were a number of GitHub like services you could
| self host but gitea stood out to me as the easiest to
| install and maintain. A lot of the other options I looked
| at required multiple daemons, a full database, etc. Gitea
| can use a full database but works great with SQLite also.
| mwint wrote:
| Side track, but what circumstances/choices lead to spending
| most of your time at AirBnB's?
| zxcvbn4038 wrote:
| I didn't leave my apartment for two years because of Covid
| and decided a change of scenery would be nice, so my family
| and I have been bouncing around rural AirBNBs for about six
| months. Though we'll have to go back in another month - my
| son really wants to go back to in-person schooling, that is
| starting soon. But back to the woods as soon as he gets tired
| of high school life!
| macspoofing wrote:
| >it was about the only option for a self hosted private repo
| with a GUI.
|
| Bitbucket had free private repos for a long time. There were
| other services as well.
| tbrownaw wrote:
| > _as a Tor hidden service which makes it easily accessible
| from almost anywhere_
|
| I have a wireguard with the server running on a small VPS,
| which is useful for both ignoring filtering on public wifi and
| getting into my home network from wherever.
| quaintdev wrote:
| I'm thinking of doing this but at the same time I'm afraid of
| exposing my home network to a remote VPS. Am I being too
| paranoid about this?
|
| If I do go this route do you have any suggestions with
| respect to security?
| [deleted]
| tbrownaw wrote:
| The VPS is running sshd (pubkey auth only) and Wireguard,
| and I also see bound UDP sockets for dhclient and ntpd. And
| that's it, at least for the public interface.
|
| Also, things I want to look at on my home network mostly
| work fine over ssh (console stuff, git, etc). So I haven't
| actually gotten around to setting up full routing yet, and
| use the wireguard endpoint box as an ssh jumphost / bastion
| (and can forward ports if I do have something to get at
| that doesn't like to play nice).
| VTimofeenko wrote:
| I have a similar setup and I was also quite paranoid at
| first. Wireguard is a very solid solution that does
| precisely what it claims to do and allows you to layer
| extra network controls on top of it, so the vpn clients
| only get routed where you allow them to.
|
| A bit less hands-on solution could be something like
| tailscale.
| stormbrew wrote:
| You can lock down a wireguard vpn server pretty hard,
| because wireguard itself is essentially invisible unless
| you know it's there. It doesn't respond to anything but
| well formed, correctly signed (in the case of connection
| initiation) or encrypted (for the actual network itself)
| packets. So conceivably, you can have your vpn server not
| respond to public icmp, not expose even ssh without
| wireguard under it, and be essentially invisible to the
| internet.
| fs111 wrote:
| If you are not replying to ICMP you let everyone know
| that you are there. If you we're not there, the error
| would be 'no route to host', but there is a route, so you
| must bei there
| Fronzie wrote:
| For me, https://tailscale.com/ gives me an easy-to-use
| personal network. It uses wireguard with custom
| configuration on top of it.
| zxcvbn4038 wrote:
| One of the benefits to Tor is you don't need to open any
| ports, the Tor acts as a reverse proxy for onion services.
| A lot of Tor services run over port 443 because it gets
| passed through with little to no issue. With Wireguard you
| have to deal with all the networks, particularly airports
| and businesses, that don't allow UDP. I've had a good bit
| of luck using the dns and ntp ports for wireguard but if
| your on a network that has something filtering/monitoring
| dns or only wants you to use their time server, those can
| stop you also. Once http/3 is official that should make
| things better for everyone using wireguard.
| TheaomBen wrote:
| Plus tor hidden services -or whatever the current
| nomenclature is- offer a fairly robust and painless story
| for authentication in this "sorta VPN" scenario. Generate
| a couple extra keys and invite a friend and his bots.
|
| https://community.torproject.org/onion-
| services/advanced/cli...
| zxcvbn4038 wrote:
| I do the client auth feature. The chances of someone
| stumbling across my hidden service is pretty low I think,
| but it's not zero. With auth set up I don't think a Tor
| client can even get the Id of the rendezvous server
| without having the correct key.
| siddontang wrote:
| Gitea is very easy to use, but I find the Activity feature is a
| little slow.
|
| I experienced the "Try Gitea" service and migrated our TiDB repo
| https://github.com/pingcap/tidb to it. When I clicked the
| Activity tab and selected "1 year" period, I found the page
| loading was so slow, nearly _90s_. And I also found that this
| Activity doesn 't have a Cache, I re-selected "1 year" again, and
| the page loading was nearly the same time.
|
| I guess Gitea uses git command to traverse all the logs for the
| period every time. Maybe it can use a database to speed up, or
| like Github only provide at max "1 month" period.
| capableweb wrote:
| Could just be because the "Try Gitea" service is just a test
| deployment, staging environment if you will. I don't think it's
| optimized in any way at all.
|
| Trying to same on Codeberg, which is a production environment
| of Gitea, the loading time of the "Activity" page for
| Codeberg/gitea seems to take ~5 seconds for me. It still seems
| to lack any sort of caching, but at least it's relatively fast.
| See https://codeberg.org/Codeberg/gitea/activity/yearly (people
| might want to be careful hitting that URL over-and-over, in
| case we ddos the Codeberg folks :/ )
___________________________________________________________________
(page generated 2022-06-05 23:01 UTC)