Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gitlab 10.7 Released

about.gitlab.com

Post reply on HN
Print view View original

21–30 of 84 posts

Re: Gitlab 10.7 Released

#21

Post by fb03 »

trashcan wrote: post #4
dijit wrote: post #2

I know its not as sexy as new features, but I really wish gitlab took a look at performance. Currently its sitting at 9GiB of Memory on my dedicated server box for basically no users. I tried it on smaller instances but it was so painfully slow I ended up getting a cheap dedicated server from Hetzner.

Agreed. I really would prefer to use Gitlab, but at the moment I'm using Gogs on my Linode instance because it runs smoothly in <1GB of RAM.

That's what I've been using and idk if I need that much many features. Gogs gives me https+ssh, and a proper sane ui to quickly create accounts and config things. It's so lightweight I don't see me migrating to bigger stuff anytime soon.

Any clue on what gitlab-only features people need that makes Gogs unusable or unfitting? make me really curious

Re: Gitlab 10.7 Released

#22

Post by jancsika »

> For example, you may now define which jobs you want to run just by tuning project variables, or you can restrict a job to be scheduled only when the variable is equal to a specific user.

How would this be used in practice?

For example-- suppose I want to give certain users access to my runners when they make a merge request. Can I use GITLAB_USER_NAME in .gitlab-ci.yml to achieve this?

Re: Gitlab 10.7 Released

#23

Post by sytse »

jbk wrote: post #18

I, for one, am very impressed by the capability of this (mostly-remote, IIRC) team to ship so many releases, so fast. We have now one release per month! We host most VideoLAN projects on our own instance, and the updates are now very smooth, especially compared to the beginning. Of course, there are features that we care about a lot and are not implemented, because they don't consider them important (or maybe not wor…

Awesome that your upgrades are smooth, thanks for posting. We're indeed a completely remote team, see https://about.gitlab.com/culture/remote-only/

And we do want to make sure that all the features you really need are there. I understand the VideoLan needs https://gitlab.com/gitlab-org/gitlab-ce/issues/40321 and we're prioritizing it.

Re: Gitlab 10.7 Released

#24

Post by sytse »

zegerjan wrote: post #17
songzme wrote: post #15

I wish I could understand the value add of yet another IDE. The whole reason for tech to exist is to improve things around the world, and yet brilliant minds are still spending years building one IDE after another. "Switching branch and remembering branch names..." is a simple git status. On vim, you can get a file browser on the left by using nerdtree plugin, and to write commit messages on the right side you simply…

I've used it a couple of times now not to develop, but to incorporate review discussions and minor other fixes. But from my perspective the true value is for non developers, or when you're starting with Git. No need to worry about remotes and what you did or didn't sync. Or if the branch is even there and you need to set the upstream. Concepts one need to get now are branches and commits. No cloning, fetching, pullin…

Yep, it is also really nice to contribute to a repo that you didn't work on before and probably won't work on after. No need to wait for a clone anymore. Our mission is everyone can contribute and we hope this will make that even easier.

I agree that as an industry we should spend more time on impactful things. That is why we based our IDE on the awesome Monaco editor of Vs code that was open sourced by Microsoft.

Re: Gitlab 10.7 Released

#25

Post by sytse »

trashcan wrote: post #19
sytse wrote: post #12

Earlier quoted context omitted.

Thanks Scott for linking to that. We're very much trying to improve the performance of GitLab. I do think that most of our performance improvements are to improve the end-user experience. So I totally understand dijit's request to reduce memory. Today we recommend 4GB of memory to run GitLab https://docs.gitlab.com/ee/install/requirements.html#memory One big thing would be if we can run the Ruby code multithreaded ht…

Are there any plans or targets to lower the memory requirement?

Apart from everyone wanting to see multithreading happen there is no target or date.

Re: Gitlab 10.7 Released

#26

Post by [deleted] »

no_protocol wrote: post #11
transmit101 wrote: post #8

I implemented the HTTPS-only Pages feature in this release. I just wanted to say that GitLab is a great project to contribute to, with a very friendly and professional community! Definitely recommend to anybody interested in contributing to a project themselves. [1] https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/16273 [2] https://about.gitlab.com/contributing/

Thank you. The issue thread/request for this had been open for something like 2 years and I waited patiently for someone braver than me to implement it. Now my custom domain on GitLab Pages automatically redirects to HTTPS. I'm happy. Next up is to add an option to automatically renew Let's Encrypt certs for GitLab Pages.

[deleted]

Re: Gitlab 10.7 Released

#27

Post by jbk »

sytse wrote: post #23
jbk wrote: post #18

I, for one, am very impressed by the capability of this (mostly-remote, IIRC) team to ship so many releases, so fast. We have now one release per month! We host most VideoLAN projects on our own instance, and the updates are now very smooth, especially compared to the beginning. Of course, there are features that we care about a lot and are not implemented, because they don't consider them important (or maybe not wor…

Awesome that your upgrades are smooth, thanks for posting. We're indeed a completely remote team, see https://about.gitlab.com/culture/remote-only/ And we do want to make sure that all the features you really need are there. I understand the VideoLan needs https://gitlab.com/gitlab-org/gitlab-ce/issues/40321 and we're prioritizing it.

> We're indeed a completely remote team, see https://about.gitlab.com/culture/remote-only/

That's very hard to keep at a constant pace.

> And we do want to make sure that all the features you really need are there.

So far, everything is great, but we would love to have:

- Custom Fields, in order to leave trac (such a pain, this service is);

- A way to fork/MR across Gitlab/Github instances: we don't want our instance to become yet another forge, people should use gitlab.com/GH. We would like that people can fork our projects on gitlab.com/github.com and then send PR our way. I understand this is über-hard, but that would be very nice;

- Be able to update a MR without push-forcing on the same branch, but with a new branch (that allows better reviewing of older versions).

(Btw, we currently use jenkins and we will move to gitlab-ci.)

Re: Gitlab 10.7 Released

#28

Post by jasone »

jbergstroem wrote: post #14
dijit wrote: post #2

I know its not as sexy as new features, but I really wish gitlab took a look at performance. Currently its sitting at 9GiB of Memory on my dedicated server box for basically no users. I tried it on smaller instances but it was so painfully slow I ended up getting a cheap dedicated server from Hetzner.

It might be worth mentioning that they use jemalloc which greedily allocates memory. I "found out" while running into an issue and disabled it[1] which shaved a fair amount of memory from allocation. At the end of the day I guess it didn't matter - for me - seeing how I didn't need that memory for anything else. Also, the cookbook for setting up postgres also takes your total ram into account. 1: https://gitlab.com/g…

jemalloc does not greedily allocate memory, and it's not clear to me how you would think so from reading that gitlab issue discussion. I can well imagine jemalloc not behaving as desired under certain conditions, but if so it's surely more involved than wanton naivete.

Re: Gitlab 10.7 Released

#29

Post by boudin »

fb03 wrote: post #21
trashcan wrote: post #4

Earlier quoted context omitted.

Agreed. I really would prefer to use Gitlab, but at the moment I'm using Gogs on my Linode instance because it runs smoothly in <1GB of RAM.

That's what I've been using and idk if I need that much many features. Gogs gives me https+ssh, and a proper sane ui to quickly create accounts and config things. It's so lightweight I don't see me migrating to bigger stuff anytime soon. Any clue on what gitlab-only features people need that makes Gogs unusable or unfitting? make me really curious

There's the whole CI part. Gitea miss code comments for code review. Gitlab also have project management tools like issue boards And surely some other things i haven't looked into

Gitea definitely do less but do it well and much in a much lighter way

Re: Gitlab 10.7 Released

#30

Post by jbergstroem »

jasone wrote: post #28
jbergstroem wrote: post #14

Earlier quoted context omitted.

It might be worth mentioning that they use jemalloc which greedily allocates memory. I "found out" while running into an issue and disabled it[1] which shaved a fair amount of memory from allocation. At the end of the day I guess it didn't matter - for me - seeing how I didn't need that memory for anything else. Also, the cookbook for setting up postgres also takes your total ram into account. 1: https://gitlab.com/g…

jemalloc does not greedily allocate memory, and it's not clear to me how you would think so from reading that gitlab issue discussion. I can well imagine jemalloc not behaving as desired under certain conditions, but if so it's surely more involved than wanton naivete.

I explained poorly. I ran into issues with updating jemalloc as part of a software update. While debugging the issue I disabled jemalloc (unsetting the ld_preload) and noticied a sharp difference in how much memory ruby had allocated. I guess _pre_allocating is incorrect and a better explanation is _not releasing it_. Thanks for rebutting my argument and giving me the opportunity to elaborate.
Post reply on HN