Earlier quoted context omitted.
Plugins and configuration are a given, but it’s something you do once upfront as part of the setup. Not sure how other tools handle this, though. And yes, you do end up needing to use Groovy for anything non-trivial.
And then somebody needs a different, incompatible, version of plugin X and you set up another Jenkins master. Or upgrade the the Jenkins master and watch other jobs fail. And not to mention plugin Y and plugin Z crashing Jenkins when being run together because they share the same classpath. While in the meantime one of the developer is trying to migrate his pipeline from one master to another and he finds out that of…
Jenkins Is Getting Old
281–290 of 340 posts
Re: Jenkins Is Getting Old
#282Hello, I see a lot of great feedback in this post. I am a product manager working at CloudBees, the primary corporate sponsor of Jenkins. Jenkins is now in the Continuous Delivery Foundation as well. While it is easy to bash on an inanimate object, there are some very dedicated and empathetic people who care deeply about the project. Some of those people do this work in their off-hours and some to this work as part o…
Debugging Pipelines/Groovy is horrible. The stacktraces are horrible. You don't even get a line number for the error!
Also, the documentation badly needs updates and examples.
(Also, amusingly, we chatted a bit by mail on April 25th 2018, but there was no follow up on your side, I guess priorities changed...)
Re: Jenkins Is Getting Old
#283I sincerely wish I could move away from Jenkins for the reasons stated in TFA (GUI-oriented, slow, hard to backup/config, test-in-production mentality and boundless plugins) but I've never found something that fits the bill. The much-touted repo integrations (travis, circle...) all have an exclusive focus on build-test-deploy CI of single repos. But when you have many similar repos (modules) with similar build steps…
TeamCity from JetBrains is the same thing as jenkins, except the core features are working core features instead of broken plugins. It's paid software though, you get what you pay for. https://www.jetbrains.com/teamcity/ On the other hand there is Bamboo from Atlassian. https://www.atlassian.com/software/bamboo I really don't understand this mentality of there is no better tools when there are better tools than jenki…
My experience of Bamboo has included:
* Broken base Ubuntu images being recommended by Atlassian as the default for agent Image configuration, only to be fixed to a usable state months later;
* Being generally years behind other CI tools, even the traditional ones;
* Data exports corrupting themselves despite apparently succeeding, blocking migrations after upgrades or server changes;
* The official documentation somewhere recommending copying across password hashes directly for setting up new admin for a migration, but I can't find this anymore so they've hopefully improved the process and documentation for this;
* A bug in an earlier version in which a strange combination of error cases in an Elastic Bamboo image configuration could spam EC2 instances in a constant loop, which we thankfully spotted before it ate through our AWS bill;
* No clear messaging from Atlassian about how the future of Bamboo compares to Pipelines. The official line seems to be that Bamboo is for highly custom setups who want to host their CI themselves, but you get the impression from to the slow pace of development that they're slowly dropping it in favour of Pipelines. I'd rather they be honest about it if that is the case.
Those are just the problems I can think of from the top of my head, anyway.
Re: Jenkins Is Getting Old
#284Anyone looking for a more back-to-basics self-hosted CI might be interested in Laminar[1] - this article reminds me why I was inspired to write it
Re: Jenkins Is Getting Old
#285Disclaimer: I'm pretty biased towards Gitlab -- write about the things you can do it from time to time and they gave me some free swag once. Best CI I've ever used is Gitlab CI[0]. The runner is completely open source[1] and you can use your own runner with your gitlab.com (or local instance) projects -- set it up in an autoscaling group[2] for savings. I run https://runnerrental.club but Gitlab also recently release…
Multirepo pipelines behind a paywall is a good reason to say "No, thanks".
Re: Jenkins Is Getting Old
#286Disclaimer: I'm pretty biased towards Gitlab -- write about the things you can do it from time to time and they gave me some free swag once. Best CI I've ever used is Gitlab CI[0]. The runner is completely open source[1] and you can use your own runner with your gitlab.com (or local instance) projects -- set it up in an autoscaling group[2] for savings. I run https://runnerrental.club but Gitlab also recently release…
Multirepo pipelines behind a paywall is a good reason to say "No, thanks".
what is your alternative please ?
Re: Jenkins Is Getting Old
#287Earlier quoted context omitted.
We had the problem that whenever we built a project it would trigger builds of any project that transitively depended on that module. So if you have e.g. 26 projects depending on each other in a line and you make a change to the first one, in jenkins this will run 26 builds as it builds A, then B, then C, .... . Whereas in Teamcity it will run 26 + 25 + 24 + ... builds: it'll build A, then B-Z immediately, then the b…
It sounds like those builds weren’t quite set up correctly. I’ve used TeamCity’s build chains quite a bit and haven’t seen this behavior. Depending on exactly how the builds are triggered it will sometimes enqueue redundant builds, but as the duplicates come to the top of the queue the server realizes they’re unnecessary and doesn’t run them.
There was no "TeamCity build chain", just normal maven dependencies. We raised the issue with their official support (we had a commercial contract) and they couldn't fix it either. Whereas Jenkins did the right thing by default. Shrug.
Re: Jenkins Is Getting Old
#288OP really needs to try Concourse. Same container-based workflow as Drone that is touted as a solution, but more mature, and much more testable than Drone. Concourse really hits his requirements for ops-friendliness and testability. It's easy to upgrade because the web host and CI workers are completely stateless, and the work you do with Concourse is easy to test because the jobs themselves are all completely self-co…
> ops-friendliness
certainly I love the idea of concourse as a release engineer but the lack of a nice UI for dev feedback/monitoring makes it a hard sell as a drop-in jenkins replacement
Re: Jenkins Is Getting Old
#289We use Jenkins at work and have found a pretty damned sweet spot. Let me start by saying that we used to use GitLab, a lot of it was because of the CI but I didn’t have a great experience trying to manage it on top of Kubernetes, they’ve since introduced a Kube native package and I’ve been told it’s much easier, but with the deployed omnibus we ran into a lot of issues with runners randomly disconnecting, it became f…
I want to specify this is my own experience and I think a lot of our own issues may have been from mismanaging our self-deployed setup. I’ve had a lot more experience managing Jenkins. GitLab and their approach to CI (easy to use yaml) really facilitated developers writing CI, which increased our software quality overall.
Have you used the Jenkins Job DSL plugin?
I'm just getting started using it, but it seems like the solution to scaling up to a lot of Jenkins jobs. There's a good talk about it, and since you're one of only two people in the thread who used the word DSL and you are having a good experience with Jenkins, I thought I'd ask.
My config is similar except my single EC2 node is actually running Kubernetes via kubeadm, it's a single node Kubernetes cluster and has enough room for about 3 of my worker pods to execute concurrently before the rest have to wait.
(But that's just my setup and has nothing to do with Job DSL.)
For me, managing Jenkins via the helm chart has been the best part of the deal, but I'm a pretty big fan of Helm already...
Re: Jenkins Is Getting Old
#290I sincerely wish I could move away from Jenkins for the reasons stated in TFA (GUI-oriented, slow, hard to backup/config, test-in-production mentality and boundless plugins) but I've never found something that fits the bill. The much-touted repo integrations (travis, circle...) all have an exclusive focus on build-test-deploy CI of single repos. But when you have many similar repos (modules) with similar build steps…
TeamCity from JetBrains is the same thing as jenkins, except the core features are working core features instead of broken plugins. It's paid software though, you get what you pay for. https://www.jetbrains.com/teamcity/ On the other hand there is Bamboo from Atlassian. https://www.atlassian.com/software/bamboo I really don't understand this mentality of there is no better tools when there are better tools than jenki…
We use Teamcity even though we have Gitlab for source control. Teamcity has worked for years which we needed. Don't know if we ever will switch to Gitlab for CI.