I hate, on a fundamental level this whole "bash in YAML" trend. Let's take a powerful, turing complete language and put it in a _config file_.
What? I don't even...
And the fact that you only get _one_ .gitlab-ci.yml file. That is legitimate madness. Want modularized CI/CD configuration? Not in these parts, buster. Have submodule build dependencies? We laugh at your use case.
Sure as shit better than Jenkins though.
This is why I hate Ansible. Looks simple until you need to do something complex, and then it becomes horrible. Chef's use of an actual language is far better, though on the flip side it's much harder to provide any kind of interface to configure it outside of a text editor.
If only there were some language where config data and code were the same data structure. (hmmmmmm)
On top of it, using ruby was a big pain when trying to work with rvm (e.g. for deploying ruby apps or developing ruby apps and running chef commands locally). Things may have gotten better since I last suffered through Chef, but we started running towards terraform + cloudformation.
Instantly reminds me of SICP and Lisp, code is data.
Do you perhaps mean syntax rather than structure? (Or a subset of the syntax.)
If I've guessed correctly, that language has already been wedged into lots of places that it's a poor fit, so I guess there's precedent there.
Was I wrong? If it was meant to be a reference to Lisp, I take much of it back.
This for us represents our vision so far on where we want to take GitLab CI next and I think addresses where you see gaps with our product today - we see them too.
That's a feature. You don't want to reason in Turing languages, you want to reason in a mostly restricted grammar with its Turing-complete escape hatches clearly pointed out.
You can also have templates, special jobs starting with dot.
Where do you see this? Looking at https://gitlab.com/gitlab-org/gitlab-ce/issues/18157 it seems this kind of support is still not started
see https://cd.foundation/ & https://jenkins-x.io (it works with Jenkins if you like, but natively uses the new pipelines and no SPOF masters). Might not be for everyone but worth a look.
disclosure: cofounder of cloudbees here (wanted to comment on original article but not able to for some reason on medium).
But if that isn’t for you https://www.cloudbees.com/products/cloudbees-jenkins-distrib... aims to simplify the Jenkins config.
It isnt' for everyone (and I wouldn't want to run it myself - GKE or EKS is fine but otherwise.. it seems tough to run).
Also this is really a starting point for Jenkins X - I expect options for non kubernetes to be coming.
I also like to plug VSTS in these conversations. It’s really nice to be able to drill down from feature roadmap to build status in a single tool without a lot of config. I haven’t built anything complex in it personally, but hear nothing but good things from the teams I work with who do.
Edit: looks like I had the bamboo thing backwards; but I remember I stopped using it for a reason :)
What do you mean by this? Is this not the self hosted version?
[0] It's unfortunate that big open source projects are never willing to pivot when fundamentals of the original design are shown to be bad. Rarely used features, for example, are never removed in order to make the software better for the overwhelming majority of users.
The main problem with runner is that you cant easily execute build script on the host. Exec command isn't very useful and AFAIK deprecated.
What do you want to do on the host?
This is not the same as taking a bash/powershell script and running it locally on runners host because gitlab inject into shell some stuff like secrets, env vars, artifacts, caches etc.
Some errors are VERY hard to reproduce when not on local executing environment.
I agree! I think that we have lots of improvements to make here. One feature that is underutilized (more on that in a second) that tries to answer this is our [1] interactive web terminal that lets you connect directly to the container or runner that is running a job. Would love feedback on how that could maybe help here.
Now, having said that there are two issues still open that are top of mind for making this minimal viable change much more usable. One is making the Web Terminal work in our shared runner pool on GitLab.com [2]. This is obviously required for users of .com who don't want to bring their own runner and something we're working closely with our Production and Security teams on making a reality.
In addition, there is a command today of `gitlab-runner exec` that allows you (in theory) to install the GitLab runner locally and execute it on your development machine. However, we technically depreciated that and have plans to re-implement it in a more useful way. [3]
[1] https://docs.gitlab.com/ee/ci/interactive_web_terminal/
We are also working at CloudBees to have CodeShip support the emerging Jenkins X Pipeline syntax (YAML that mirrors the functionality of the Jenkins Pipeline). This syntax was based on the Tekton project, driven by the Continuous Delivery Foundation and significantly influenced by Jenkins developers like Andrew Bayer and Devin Nusbaum and by their PM, Nofar Bluestein.
No, nothing in the cloud, no system you don't fully control is an option in my IT business. Forever. The only thing I tolerate is something totally irrelevant most of the time, (like statuspage maybe), easily replaceable and package repositories (but only because you can install local proxy so once pulled is on premise FOREVER).
Then you have a root shell on your target device (I leave the "should" as an exercise for the user )
But, It won't work using the free shared gitlab runners.
However since the reliability has improved 10 fold in the last year, it seems less worthwhile.
I do however have a number of gitlab runners running on our own stuff. WE also have an autoscale integration to save money on GPU machines.
External partners have costs. And really the kind of things we need these things for here are pretty easy to configure in a Docker container.
What we expect we’ll end up with after the Jenkins switch is Cloudformation templates we can hack into a Circle CI replacement.
And we’d use GitLab if we could start over there but are bought into some end user tools and workflows that connect to GitHub that people don’t want to give up. BUT no one cares about Jenkins going away since they use it through a Slack bot ️
This doesn't make sense to me. Jenkins is a CI tool - that means it can build, test, and deploy your code.
EKS is a managed Kubernetes instance. That means it can run a collection of Docker containers.
I don't see how EKS can accomplish building or testing.
> "... suck massive genitals..."
I cannot believe that this is the top-voted comment.
was it because I mentioned genitals, or should I use stronger coprophilic comparative adjectives instead?
or was it because expressing intense dislike for a slow, arcane and frustratingly inconsistent UI.
Its not like I dismiss jenkins out of hand. There are still strong usecases. But there better, simpler, repeatable alternatives
Any one click can be a gateway into a one million miles deep rabbithole of unbridled mediocrity and brokenness.
Its badly laid out, inconsistent and worst of all lazy loading. So its not like you click a button and everything displays.
No, you click a button and wait 1.5 seconds whilst everything jiggles about.
Has been abused by three teams of developers.
Its not been updated in two years.
Where is that builds thats failing? what has changed? what are the active plugins, who updated them, and when?
etc, etc, etc,
All of this requires a massive amount of clicking, and because it lazy loads in some versions, it can tak >3 seconds to load a page.
At its peak I had to shepherd ~50 masters of varying ages, plugins and levels of customisations.
Yes, it allowed repeatable builds, and it can be, in certain circumstances a very good replacement for cron jobs where you need to administer >5000 machines.
However, it has an offensive UI, the plugin system appears to be designed to deliberately cause things to break, versioning the flows is difficult, unless you rely on plugins (which break) or want to learn groovy.
Automating and making jenkins it's self repeatable is a soul sapping task.
In short, jenkins needs to disappear.
Yes, cirle is crap, bamboo suck massive genitals.
However I have had great success with gitlab runners. Now that gitlab is actually reliable, they are a brilliant first class integration into a git workflow.