Hacker News Reader

Comment by intsunny | Hacker News Reader

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.

View on HN

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

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.

Reply on news.ycombinator.com