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

Take Gitlab to the command line with GLab, an open-source Gitlab CLI tool

github.com

Post reply on HN
Print view View original

41–50 of 76 posts

Re: Take Gitlab to the command line with GLab, an open-source Gitlab CLI tool

#41

Post by brodock »

ianbooker wrote: post #13
mattl wrote: post #5

Earlier quoted context omitted.

How much RAM? Are you installing from Omnibus packages? I ask because I have two servers and have near perfect uptime.

64 GB on a 16 core machine that has nothing else to do. If any, I think this is maybe too much, every worker just spawns more and more workers. I restricted Postgres from taking all RAM, Sidekiq and Puma to low numbers. But there are more.. I follow the instructions straight from Gitlab.

Consider having databases in a separate instance. 2x32GB is better than one 64GB.

It's specially important at this size to have git in a different machine than the database as both are I/O constrained.

Re: Take Gitlab to the command line with GLab, an open-source Gitlab CLI tool

#43

Post by xav0989 »

nhumrich wrote: post #38
hobo_mark wrote: post #27

Earlier quoted context omitted.

But GitLab already has repo mirroring built-in, what am I missing?

it's a paid feature: not in community gitlab

Pushing from gitlab to another git host is free and in the community edition[1]. Pulling on the other hand is a paid feature.

[1]: https://docs.gitlab.com/13.2/ee/user/project/repository/repo...

Re: Take Gitlab to the command line with GLab, an open-source Gitlab CLI tool

#44

Post by stevekemp »

techntoke wrote: post #23

Anyone else switched entirely to Tekton or another CI/CD platform because GitLab feels like a bloated monolith and too centralized at this point?

Gitlab has been "concentrating on performance" for literally years at this point. Their evangalists always point at open bugs, and show progress every time a new release is made, and yet I can't recommend it.

I wish I could use gitlab more, because I loved their runner-system. Nice and useful, and some of their integrated systems are really nice (such as the container registry). But at the same time so much stuff has been bolted on, seemingly in a hurry, that it's hard to recommend unless you're a masochist.

On the plus side of course Gitlab, and source hut, as well as the other lighter-weight systems do provide pressure to Github - so even if I don't use them again their existance is useful.

Re: Take Gitlab to the command line with GLab, an open-source Gitlab CLI tool

#45

Post by gru »

hobo_mark wrote: post #27
gru wrote: post #8

Earlier quoted context omitted.

I have created a small tool that automatically mirrors public repos from GitLab to GitHub: https://github.com/grdl/gitlab-mirror-maker Meaning, a repo can be hosted on GL but still benefit from better exposure and disoverability of GH.

But GitLab already has repo mirroring built-in, what am I missing?

You're not missing anything. It does use GitLab's mirroring API. However, GitLab doesn't have any global mirroring settings, you need to set up each repo individually. The tool just saves you a huge bunch of clicking around and copy pasting auth tokens. Useful if you have a big collection of repos you'd like to mirror. And if you'd like every new public repo to be mirrored automatically.

Re: Take Gitlab to the command line with GLab, an open-source Gitlab CLI tool

#47

Post by boleary-gl »

gru wrote: post #8
mosselman wrote: post #2

Hosted on github. Ah the irony. Feels like a missed opportunity. On another note no have been using the GitHub cli client and it is great to be able to quickly create a PR from where I did the last push.

I have created a small tool that automatically mirrors public repos from GitLab to GitHub: https://github.com/grdl/gitlab-mirror-maker Meaning, a repo can be hosted on GL but still benefit from better exposure and disoverability of GH.

This is awesome! Thanks for sharing.

Re: Take Gitlab to the command line with GLab, an open-source Gitlab CLI tool

#48

Post by hoistbypetard »

ianbooker wrote: post #4

My new hobby is installing vanilla Gitlab CE on a vanilla server and waiting until it crashes the whole thing. Takes something between 8 to 36 hours. The server is completely gone, no ping, no ssh. It takes frantic remote power button pushes to even turn it off. Afterwards I reconfigure various config lines and repeat.

I mean this with no judgement: that is a weird hobby.

Is there a reason you do that instead of fixing gitlab or just using something else? Either of those would seem more satisfying to me.

Re: Take Gitlab to the command line with GLab, an open-source Gitlab CLI tool

#49

Post by mcintyre1994 »

fileeditview wrote: post #30
gru wrote: post #8

Earlier quoted context omitted.

I have created a small tool that automatically mirrors public repos from GitLab to GitHub: https://github.com/grdl/gitlab-mirror-maker Meaning, a repo can be hosted on GL but still benefit from better exposure and disoverability of GH.

How I usually do it if I want to have my project on Github and Gitlab is configure two push remotes like this: > git remote set-url --add --push origin > git remote set-url --add --push origin This way I have an automatic backup to the second remote.

Does this mean when you `git push origin ` it gets pushed to both remotes? I had no idea you could have two remotes with the same name, neat!

Re: Take Gitlab to the command line with GLab, an open-source Gitlab CLI tool

#50

Post by awild »

intsunny wrote: post #32
mosselman wrote: post #2

Hosted on github. Ah the irony. Feels like a missed opportunity. On another note no have been using the GitHub cli client and it is great to be able to quickly create a PR from where I did the last push.

I suspect due to the sheer number of internal deploys, Gitlab does not always get the exposure warranted. My work place is switching from internal Gitlab/gitlab-runners to external gitlab.com + internal gitlab-runners. We are very happy with both scenarios, but neither gains Gitlab any exposure.

Can you expand on that scenario, how are you hosting the internal runners? Our gitlab server is quite limited in capacity and that would actually be a cool solution to outsource them onto our bigger servers.
Post reply on HN