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.
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.
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
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
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.
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.
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.
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.
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.
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 :(
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?
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..
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.
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
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.
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.
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.
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!
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.
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.
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.
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.