|
|
|
|
|
|
by stevekemp
2399 days ago
|
|
|
> the upgrade process has always been pretty smooth By contrast I've managed a self-hosted install a while back, upgrades regularly broke as much as they fixed. For example the time when LDAP logins all failed, the gitlab-pages stopped working, and more. That's on top of the constant UI churn with the side-menu, and similar changing from release to release with no rhyme or reason. I wanted to like it, and did like the runner/CI support, though even that had as much pain as love. (Hard to script installation of agents, etc.) |
|
|
Anyway, for CI-runner setup, I have a one-liner that worked for me: bigsudo install lean_delivery.gitlab_runner @somehost gitlab_ci_token=yourcommand gitlab_host=yourlabs.io gitlab_runner_limit=4 gitlab_version=11.6
But also a docker run does the job... Well, there's still registration of runner that I did manually, but I just checked ansible documentation and it really looks like I got a fair chance to achieve that too, given all the new modules ansible got since 2.8 to deal with gitlab, including gitlab_runner and gitlab_runners modules: https://docs.ansible.com/ansible/latest/modules/gitlab_runne...
So yes, Gitlab strives to keep development and releases coming, that means sometimes foundations move, and that there's a learning curve too, I understand that some people may not like that, but as a dev myself I like it this way, and at the end of the day my team iterates great with GitLab-CI, we got automated review-deploys in less than 5 minutes with just docker-compose and that's really helpful to keep the master branch clean, this allows features to be merged only after they have received product team approval so that's a big win. With GitHub you can also do it with Drone-CI which you might like better because it's easier to setup even though it remains behind GitLab-CI in terms of features that matter to me.