Replacing Jenkins has been... a frustrating experience met with nothing but hollow shells of services. We want to self-host, we want something that can deploy our code, we want to be able to write arbitrary jobs not tied to specific github projects.
The Jenkins ecosystem is atrociously bad. Don't get me wrong, it's incredibly active, but it promotes a "just make a plugin for everything" attitude which results in things like, plugins to echo this or that, plugins to do a million things better done from the shell, etc. On top of that, the Jenkins UI is just... bad. It's ugly and it's a UX disaster. I could go on.
Yet, there's nothing better than Jenkins out there right now. Drone claims to want to replace Jenkins, but doesn't even have support for arbitrary jobs. I'd love more recommendations.
This is why, a while back here on HN, I asked if I could pick up the Gitlab job runner in golang and slap a different web UI on top of it that manages the jobs. This doesn't appear to be possible but I see the value in such a runner existing. Running the jobs is a critical component of such tools.
I just finished setting up a complete pipeline for a new business with my cofounder: Jenkins was a big pain point. Terraform was a pain point. Ansible was a pain point. Getting a vault solution set up and done right was a massive pain point. We've been striving to make things as simple as possible for developers so I wish you the absolute best of luck in what you're doing, I'm continuously impressed with Gitlab.
Email me if you have questions Sytse, I'd love to give more feedback -- email on my profile.
I'm not sure what you use case it but GitLab CI is pretty extensive and I hope it has everything you need. Please let me know if there is anything missing. If you want to host your code somewhere else you can still use remote mirroring to have GitLab do the deploy.
The GitLab Runner is a simple piece of software on purpose. This allows us to port it to many platforms. All the logic is in GitLab itself so it is easy to provide a lot of feedback about the status in the UI.
The idea of a runner that tests every commit on a repo is super useful. But Jenkins goes one step further by being essentially an arbitrary shell command runner. I use it for example as a CNC for running cleanup jobs, cronjobs etc.
For example, on Jenkins right now, we have a job which can trigger a bunch of load tests against our website. We can run this job indefinitely, give it arguments, it'll even run a local web server. By default, the job only runs the load test for ~10 mins.
The job is run periodically. When it fails, we get emails. After it completes, regardless of failure, it triggers a "cleanup" job which deletes the loadtest-related data from the website.
This is what I mean with "arbitrary jobs". I think it's absolutely fair to consider them out of scope, but if you want to replace Jenkins, this is what you're going up against.
Maybe you prefer the load testing code in the same repo as the application. In that case it should be two jobs that are triggered periodically I think.
I think what GitLab CI still needs is periodic jobs https://gitlab.com/gitlab-org/gitlab-ce/issues/2989 (right now the workaround is sending a build trigger for an external task).
I want to be able to just drop in some arbitrary command (e.g. df -h /some/build/agent/dir/ | grep 99%) that would not be worth it to me to write a script, commit it to git, get that deployed and running.
In fact, I AM a fan of this being in git, but the example I'd use is an improvement on TeamCity, where you can configure your job and project configurations to "commit to git" so that you can easily restore when you need to rebuild a server or reload a previous version.
Sooooo many use cases for arbitrary jobs. Many of which may be short lived, but want them automated in some way.
(speaking as a sysadmin/eng/devops/cloud dude)
The "code" in this case really lives in the Jenkins database, as it's a shell snippet. Admittedly I'm not a fan of this. However, since you're a FOSS company as well, you may have hit the case where you want to separate the code for your infrastructure from the code you're releasing in the general repository, but still build off master.
This is where Jenkins' model is quite good. I strongly dislike that it's so hard for Jenkins' metadata to be versioned in proper git repositories, but the separation of the actual code, and the CI-related code is great.
In my taste the shell snippet that is infrastructure specific should like in a small repository. An example of that for us is https://gitlab.com/gitlab-com/runbooks (although that is more process since we try to keep the code generic).
"any commits should be pushed to the upstream repository, and will end up in the GitLab repository automatically within an hour, or when a forced update is initiated."
"Wait up to an hour for things to happen" isn't a great story to pitch to team members :/ I'm also talking about at least twenty different repositories. I'll most likely have to continue using Jenkins for those projects but I look forward to using Gitlab CI on weekends.
(Not involved, just a happy user)
> I'd love more recommendations.
Then Dmitriy and Kamil (our CI lead) proposed integrating the CI coordinated into GitLab the main program instead of a standalone Ruby on Rails app. Again I was sceptical. But this has been a great success.
We have all the API's (webhooks, commit status API, etc.) to integrate well with Jenkins (and we'll make sure that we'll always play well with that, JIRA, Slack, and others). But having everything in one interface and one datastore makes for a much better user experience.
We've since doubled-down on this strategy. Bringing the entire software development lifecycle under one roof https://about.gitlab.com/direction/#scope During the webinar we'll show a demo video of how these components will soon work together. We think it is an amazing experience and everyone on our team is focussed to get it right.