Take Gitlab to the command line with GLab, an open-source Gitlab CLI tool | Hacker News Reader

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

github.com

157 pointsprofclems74 comments

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.

Hugely ironic, but not surprising since projects on GitHub get better exposure and also the ability to raise funds with GitHub sponsors.

This is true and important. But I also have to admit that I like the interface of GH more and I am just used to searching on GH - it always has been like google search for code for me.

GitLab has a dark theme though

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?

it's a paid feature: not in community gitlab

If your project is open source on gitlab.com - you get all paid features for free.

Here is a link to our program for open source projects for anyone interested! https://about.gitlab.com/solutions/open-source/ (community advocate at 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...

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.

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 <github-remote>

> git remote set-url --add --push origin <gitlab-remote>

This way I have an automatic backup to the second remote.

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

TIL that's exactly what this does, alternatively you can add them all to an 'all' remote, to make it more explicit:

https://jigarius.com/blog/multiple-git-remote-repositories#t...

However, you can add multiple URLs to 'origin' and push to them all at once.

This is awesome! Thanks for sharing.

I maintain a bunch of docker images that are purposed to run on gitlab ci, they are obviously hosted on github because only github has push-event integrations with docker hub.

I make a push, docker hub builds and publishes the image, the image is only pulled by gitlab ci.

Gitlab is great, but it lacks many popular integrations that must come from not-gitlab.

Good point. I just thought it was funny, but it is good to know that there ARE differences other than branding.

I imagine that's an oversight of sorts because you could just build the images on gitlab too.

There are ways, but:

1. I need to run gitlab ci myself on my host(s)

2. My host must be logged in to docker hub

3. Gitlab CI must run as privileged container

4. There are more hacks required to let gitlabci build the image and push as me.

on github you just authorize docker-hub to get webhooks from github, and that's it, it does the rest itself.

Can't you build and push via CI?

Too lazy to do the setup on multiple computers

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.

You can install gitlab-runner package on your own machine and register the instance in the Gitlab. It will be seen in the Gitlab panel next to all other runners.

you can create a merge request as well using only git, gitlab support it

  git push -o merge_request.create

I have it under alias `gmr`, it will use default branch as a target

And the infinitely handy "push -o ci.variable=ALPHA=BETA" or its friend "push -o ci.skip" to influence the CI job that's created, if any, due to the push

https://docs.gitlab.com/ee/user/project/push_options.html#pu...

That's the first I've read of `push -o`. Does GitHub have push options like that as well?

That's the first I ever heard of it, either, and was unable to find out if those options are exposed more generally to the CI pipeline (so can I make my own "-o" toys?)

I don't recall ever hearing of any such thing in GitHub, and their help search is so atrocious I don't know that I'd be able to find the answer even now. That said, I can't imagine that kind of customization fits into GitHub's mental model, which goes double given that they just recently even _developed_ a CI system to which one could send those options

The only reason I choose GitHub over Gitlab is the network effect.

If making someone create a new account on Gitlab means they won't contribute to a project, then I'd rather publish it on GitHub instead, even if GitHub is closed-source. The network of GitHub is intrinsic to that website and Gitlab might not ever be able to replicate the size of its userbase. (Of course, if I'm proven wrong I'd migrate.)

Yes, it doesn't help Gitlab to have this mentality, but out of the dozens of OSS repositories I've used only two have come from Gitlab. Every single other one I had originally found on GitHub.

Why would they contribute to this project if they don't have a gitlab account?

They may use self-hosted gitlab at work.

lol I was thinking exactly this

I understand the irony but here's the case where most Gitlab users only have account with their company's self hosted gitlab platform and hence can't contribute to FOSS on Gitlab unless they create another account. I hosted it on Gitlab for OSS visibility and get more users contributing to the project.

There is also just "lab"[1].

[1] https://github.com/zaquestion/lab

lab is great! The CI view in the cli felt kind of magical at the time. I was in an organization that was bizarrely using both GitHub ant GitLab, and lab+hub really helped make sense of things until we finally migrated to GitLab. Using GitHub exclusively at the new job has me really missing GitLab CI when working the GitHub actions :(

The biggest missing feature in GitHub for me is "Merge when green". I wonder why they didn't add this yet.

Lots of other options for gitlab CLIs:

https://about.gitlab.com/partners/#cli-clients

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.

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.

I have somewhat similar experience. I have 16GB of RAM, 12 CPU.

You can reduce the number of unicorn workers in `config/gitlab.rb`.

what are you seeing in the logs? OOM-killer? Also, newer versions use Puma which lower RAM needs if you are seeing Unicorn OOM Killer

Ah, my bad. I have `12.10.6 (833223f2a7f)`. Time to pull, as it really hogged my RAM. The pattern is that it will periodically consume much more resources.

Thanks for the heads-up.

That was a theory I had: That Unicorn leaks and that Unicorn Killer is not killing any of the workers, since it does so all 160 requests and there are no request happening at the moment.

Then I saw the new installation uses Puma ;)

Hi, GitLab product manager here. I'm sorry that we haven't provided a good experience. We try really hard to make sure GitLab deployments "just work", and clearly it does not for either of you.

Both Puma and Unicorn should be killed after they exceed a certain size to avoid this situation from happening. It's possible either this is not working in some situations/configurations, or there is a leak elsewhere although this is the first time I have heard reports of this.

What configuration is being changed from the defaults? Alternatively if you could open an issue with any additional detail we will try to figure out what is happening and fix it: https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues

And Gitea is usable when running on a Raspberry Pi

Disabling automatic repository housekeeping might help. It can use lots of RAM for large repositories like the Linux kernel.

The Linux kernel isn’t that bad. If you really want to kill your instance of Gitlab, try Google Chrome with all its public repos. Write a gitlab ci yaml file and configure it to build/test with every push.

https://chromium.googlesource.com/chromium/

That isn't my experience. I installed gitlab on a local debian server and it has been running for 3 months straight now.

So what's the reason for crashing? What's the configuration that you change? I assume it's not random trial and error.

Don't want to be that guy, but containerization (gitlab omnibus[0]) might actually help you in this case -- in particular the resource utilization caps that you can get with linux containers. While I can't tell you why Gitlab CE is crashing for you, it is much less likely to take down the entire machine from inside a resource-constrained container, and it will probably force you to make the configuration a bit more reproducable as well (and maybe that will help twiddling).

Would love to read about the actual config issues you're having and how you're solving them one by one -- are you writing about it anywhere?

[0]: https://docs.gitlab.com/omnibus/docker/README.html

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.

I doubt that they meant it literally. May have been a reference to the xkcd “my hobby” strips. See https://www.explainxkcd.com/wiki/index.php/Category:My_Hobby

Similar:

FWIW, a colleague at Red Hat recently began this upstream project, Bichon[1], to manage Git Lab merge requests from the shell:

"Bichon provides a terminal based user interface for reviewing GitLab merge requests. As well as an efficient keyboard based interaction model, it will allow for off-line code review caching information until reconnected to the network."

        - - -

The interface is loosely modeled after the `mutt` email client; but it's a ground-up implementation.

From what I learned (from a test spin; I'm a long-time `mutt` user myself), Bichon is not aiming to build a custom terminal-only workflow: it is mainly aims to provide an alternative to web UI. IOW, it's not an either/or—command-line and Web UI are supposed to play well together.

[1] https://gitlab.com/bichon-project/bichon/

I tried this, and it seems very useful, but there's no documentation and the CLI help command doesn't work. Why make a tool and then not tell anyone how to use it? It's frustrating. No combination of `glab help command` or `glab command --help` works.

If you want a CLI tool for Gitlab, the tool called 'lab' has existed for years and _does_ have full featured help commands, as well as a ton of other features (like live views of CI jobs in your terminal). I recommend 'lab' very highly!

https://github.com/zaquestion/lab

I downloaded it earlier, it's great! I'm going to use that, thanks.

This issue has been fixed!

Is there something similar out there for interacting with jira issues on the command line?

go-jira [1] is quite useful for avoiding Atlassian's UI.

[1]: https://github.com/go-jira/jira

Also installable via "brew install go-jira"

For anyone interested, there‘s a similar CLI for GitHub: https://github.com/cli/cli

Actually it's quite a shame for the Gitlab team that they don't offer a similar official CLI. The gitlab software is high quality in general, and obviously it's doable by a third party to implement such a tool.

I’m not so sure I’d call this shameful. The official GitHub cli is a fairly new offering and still in beta...

There is also the extra helpful hub: https://github.com/github/hub

It is a wrapper around git (you can alias it to the git command) that adds GH-aware things, like checking out a PR by URL or number, or opening up the repo page with `git browse`.

As a GitLab team membmer, this is really awesome to see! A GitLab CLI is something I'd love to have officially at GitLab. Feel free to contribute to the discussion and help up vote the idea here https://gitlab.com/groups/gitlab-org/-/epics/3324

Alternate perspective: your trying to assess demand for a feature you’re curious about building, but the community already spoke. That’s a much stronger signal than people responding to your feature-vote thread.

A CLI for a wrapper of a CLI.

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

sr.ht for me -- being able to ssh into failed builds' vms is super-duper nice

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.

Ah nice, I’ve always sort of wondered why this did not exist. It would probably be wise for Gitlab to officially support something like this.

    curl -s https://raw.githubusercontent.com/profclems/glab/trunk/scripts/quick_install.sh | sudo bash

Well if Rust does it, then it must be just fine ...

Reply on news.ycombinator.com