I use gogs at home, but run Gitlab At work - it just has so more many more features and far more customisable - also Gitlab CI rocks, it seems to scale really well - 60 active developers on a tiny vm and its lightening quick and we can easily do more than 100 releases a day.
Gogs – Go Git Service
171–180 of 186 posts
Re: Gogs – Go Git Service
#172Re: Gogs – Go Git Service
#173Earlier quoted context omitted.
Same here. Gitlab is soooo extremely slow. Even on their own site many pages take several seconds to load. And no one really seems to care. Gogs is a great relief.
GitLab.com is slow because of operational issues, like everything running from one NFS server. GitLab on your own server with enough memory should be fast. The slowness of GitLab.com is unacceptable to us, work to improve it is ongoing in https://gitlab.com/gitlab-com/operations/issues/42
Re: Gogs – Go Git Service
#174Earlier quoted context omitted.
GitLab.com is slow because of operational issues, like everything running from one NFS server. GitLab on your own server with enough memory should be fast. The slowness of GitLab.com is unacceptable to us, work to improve it is ongoing in https://gitlab.com/gitlab-com/operations/issues/42
Are you still on Azure or have you moved on? You had several blog/twitter posts about how unreliable Azure is and documented some quirks like failed reboots. But arguable you got Azure cloud for free. Don't look a gift horse in the mouth. But what's worse? I read about the problems since November 2015. Maybe invest in Google/AWS cloud and don't run it on a single NFS.
Re: Gogs – Go Git Service
#175Earlier quoted context omitted.
The problem is that we should distribute the load over multiple servers https://gitlab.com/gitlab-com/operations/issues/1 Right now the lonely repository server has over 200k context switches per second.
Your engineers probably know this, but CephFS is not well known for handing high IOPS loads; make sure to architect accordingly :)
Re: Gogs – Go Git Service
#176Earlier quoted context omitted.
The truth is, nobody personally vets the source of all the software they use. Even people who compile everything themselves aren't reading the source code that came over the wire. It baffles me when people fret over "don't blindly run that curl|bash installation script because security!" when nobody would bat an eye at a .deb downloaded from the same web site.
There are many that take an interest in securing their workstations, just as there are many negligent individuals who blindly run things they download from somewhere. A minimum amount of care when installing things (checking signatures/checksums, reading install scripts, etc) should be common sense and not doing that is grossly negligent.
Re: Gogs – Go Git Service
#177Earlier quoted context omitted.
That's how WAR files get built. It's a very standard mechanism for deploying Java apps. I think having Java on your machine is a reasonable requirement. I mean the equivalent in Ruby would be to have Ruby, install all gems and THEN launch the app.
If you actually want to run this software, JVM is a reasonable requirement: it's well-known, well-tested, easy to install, and comes in one package. It's not zero requirements, though. (Go binaries still need platform-specific libc, AFAIK, but it's usually also a reasonable requirement.)
Re: Gogs – Go Git Service
#178Earlier quoted context omitted.
It's not really a static Python .exe, but PyInstaller can create a single executable that embeds all of its dependencies in the file. Except for a small delay at startup it works really well.
This is how I distribute Grow (grow.io), a Python program. It's worked really well so far, but it's also produced a few issues in development, for me. For example, PyInstaller itself changes drastically from version-to-version, and I've previously had to spend hours picking away at why "compiled" Grow worked before but no longer works post-PyInstaller updates. Overall happy though, and much happier to write in Python…
PS: I'm the original author of PyInstaller. I obviously love it but it's a gross hack around the fact that Python doesn't have a serious distribution story.
Re: Gogs – Go Git Service
#179Earlier quoted context omitted.
Your engineers probably know this, but CephFS is not well known for handing high IOPS loads; make sure to architect accordingly :)
Thanks for the advice, do you maybe have a link with more details?
https://www.openstack.org/summit/vancouver-2015/summit-video... https://www.slideshare.net/mobile/mirantis/ceph-talk-vancouv...
Re: Gogs – Go Git Service
#180Earlier quoted context omitted.
Thanks for the advice, do you maybe have a link with more details?
Mirantis gave a talk last year at OpenStack with real-world numbers... They had to scale to 500 storage nodes to achieve 50k IOPS aggregate. https://www.openstack.org/summit/vancouver-2015/summit-video... https://www.slideshare.net/mobile/mirantis/ceph-talk-vancouv...