Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Jenkins Is Getting Old

itnext.io

Post reply on HN
Print view View original

291–300 of 340 posts

Re: Jenkins Is Getting Old

#291

Post by falsedan »

sudofail wrote: post #100

What I'd like to see is a CI/CD engine backend. Most CI/CD solutions have relatively the same feature set: - Code builds - Code deploys - Git Hooks - Parallel builds - Matrix builds - Build as configuration - Etc If there were an engine that supported these features, the community could create a number of frontends that target their specific needs. Jenkins was held back, in my opinion, for a number of years by its an…

I'd argue that the components are:

- job config

- agents & resources

- logs/results

- triggers/schedules

- web UI

- system config/'plugins'

- user directory with optional permission/ACL

and default ancillaries for secrets, artifacts, alerts, etc., with the idea that they could all be replaced with a purpose-built product that's actually good at it (i.e. Vault, Artifactory, PagerDuty/Sensu/whatever)

I think deployment is a separate problem space to CI and shouldn't be included

Re: Jenkins Is Getting Old

#292

Post by mrferos »

yebyen wrote: post #289
mrferos wrote: post #245

Earlier quoted context omitted.

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…

I haven’t used it, we use the GitHub Org Folder scan to automatically add a job for every Repo that has a Jenkinsfile- so I don’t have to do anything, it’s pretty great.

Re: Jenkins Is Getting Old

#293

Post by yebyen »

mrferos wrote: post #292
yebyen wrote: post #289

Earlier quoted context omitted.

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…

I haven’t used it, we use the GitHub Org Folder scan to automatically add a job for every Repo that has a Jenkinsfile- so I don’t have to do anything, it’s pretty great.

Awesome, that also sounds good

The big advantage of the job DSL plugin is that if you have many similar repos, you don't just treat them all the same with multiple copies of the same Jenkinsfile, you actually can build the jobs from the same source, inheritance-style.

There could be some reasons not to do this, but if you have 100 jobs and 20 or more of them are mostly identical in form except for some parameter, it's a better strategy than multiple Jenkinsfile.

But then again if your Jenkinsfile isn't changing, it might not matter.

Re: Jenkins Is Getting Old

#294

Post by wsy »

manigandham wrote: post #229
michaelneale wrote: post #131

Co-founder of cloudbees here, just some corrections: 1) there are (since 1 year) restartable builds/stages in open source (a bit over a year IIRC) - when the article mentions that they are not in open source. 2) Jenkins X is something VERY DIFFERENT from Jenkins (despite the name), it is "master less", yes requires a kube cluster to power it, but it has no Jenkins instances as you know it, in a lot of ways quite a bi…

Unfortunately people are looking for simplicity and this is going in the opposite direction. A kubernetes cluster is just offloading a large part to yet another component you have to run. Spinnaker is another completely separate system. This is the opposite of what teams want. Drone, Gitlab, Teamcity as mentioned in these comments is a far better approach for 99% of companies who want a solid working solution.

Soon, "running on Kubernetes" will be like "running on Linux", i.e., it won't add any operational complexity because you anyway have a Kubernetes cluster running.

So maybe you are not there yet, but for a future-oriented CI/CD platform with self-hosting option, using Kubernetes as basis is a good approach.

Re: Jenkins Is Getting Old

#295

Post by chupasaurus »

azdacha wrote: post #286
chupasaurus wrote: post #285

Earlier quoted context omitted.

Multirepo pipelines behind a paywall is a good reason to say "No, thanks".

what is your alternative please ?

In one of the previous jobs I've used Jenkins Pipelines (and oh boy it was PITA to set it up in 2016) to handle jobs of different projects. On current one we are using Teamcity (still cheaper than Gitlab Silver license for us) which has the support of this feature as long as branch names have a common variable in their naming convention.

I.e. Project1 has branches in form feature/TICKET_NAME or fix/TICKET_NAME, Project2 uses only TICKET_NAME, TeamCity VCS settings are based upon masks of branch names so ticket 12345 would be branch 12345 in P2 but fix/12345 or feature/12345 of P1 if one exists (priorities could be tweaked too).

Re: Jenkins Is Getting Old

#296

Post by rglullis »

chrisweekly wrote: post #231
rglullis wrote: post #55

Earlier quoted context omitted.

It is still very basic, but basically it is an alternative to pocket and wallabag, implemented in Python/Django/Celery - I actually wanted to use this as a way to learn Go, but working on the idea itself plus the potential work (activity pub, IPFS integration) became more interesting than working on learning a new language, so I changed to something I more familiar with. Anyway, the code is at https://github.com/lull…

Thanks, @rglullis, looks really cool! If I find time to play w/ it I'll let you know.

That would be great. I need to make some updates in the code and in the documentation regarding the sunset of the Mercury Parser service. Hope I can get some of it done this weekend.

Re: Jenkins Is Getting Old

#297

Post by Fewthp »

michaelneale wrote: post #248
snorremd wrote: post #57

Earlier quoted context omitted.

If you know a bit about GitLab and Docker, GitLab CI is pretty easy to grok. I really enjoy that you can run your CI jobs inside any old Docker container (with a shell). GitLab CI is built up from very simple concepts and functionalities, but still enables some powerful use-cases. The artifacts feature is great and some artifacts, like unit test report files, can be interpreted by GitLab and used in various parts of…

(Disclaimer: CloudBees cofounder here) Our hope to simplify away the checkboxing and plugins is ready to go distro (free of course): https://www.cloudbees.com/products/cloudbees-jenkins-distrib... You mention docker and it is super great for CI: it’s probably one of the widest used feature of Jenkinsfiles (you can specify what image or dockerfile you want a stage to run in - simple but powerful, as you probably know)

Good to hear CloudBees seems on top of this issue. Seen multiple posts of you guys here :)

Re: Jenkins Is Getting Old

#298

Post by oblio »

ogtifs wrote: post #284

Anyone 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 [1] https://laminar.ohwg.net/

It's not distributed, from what I see. I don't see stuff about agents.

Oh, it does, via DYI SSH, sort of. Could work, I guess.

Re: Jenkins Is Getting Old

#299

Post by eeeeeeeeeeeee »

We ran Jenkins in-house and it was a miserable experience. Always breaking. Any time we needed to update it we knew it was going to break, and it did. Debugging startup failures was always a pain if you had a moderately complex setup. There were times where it was quicker to wipe the entire configuration and start over than trying to debug it.

We switched to CircleCI and it did everything we needed and we never had to lose half a day to CI problems again.

Re: Jenkins Is Getting Old

#300

Post by vorg »

oblio wrote: post #282
jennbriden wrote: post #142

Hello, 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...)

You can use the YAML-like declarative syntax [1] instead to configure the pipelines for 90% of what you do, and just use Apache Groovy for the more complex logic, or interfacing with plugins.

[1] https://jenkins.io/doc/book/pipeline/syntax/

Post reply on HN