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

Shifting Gears

jenkins.io

Post reply on HN
Print view View original

61–70 of 123 posts

Re: Shifting Gears

#61

Post by Rapzid »

batbomb wrote: post #9

I wish we could get encrypted credentials a lá travis in a Jenkinsfile. I’ve found most configuration for a job can be in a git repo but you have to manage some things through the web interface, and it’s not that easy securely managing credentials for a Jenkins installation, even with Folders and Roles

Travis recommends storing secrets that dont change between branches via the project settings. Also, secure envars in the Travis config appears to interfere with deep merging on triggered builds.. Hopefully they can do better :)

Re: Shifting Gears

#62

Post by chinhodado »

nrclark wrote: post #21

I love Jenkins, and use it professionally. With that said, I'd really like to see better documentation on the Jenkinsfile Pipeline format. I've tried to get started with it a few times, and haven't had tons of success. Stuff like "How do I pull in secrets", and "How do I control a plugin". I appreciate that it's Groovy-based, but that's not particularly helpful information (for a hack like me, at least). The snippet-…

Totally agree. I tried to move our freestyle jobs to pipeline a few times and the experience was horrible. Official documentation was scarce, main concepts not clearly explained, there was barely any example, and god forbid if you use some unpopular plugins because chances are, the plugin does not support pipeline of if it does, good luck finding the syntax for it.

Re: Shifting Gears

#63

Post by chinhodado »

isbvhodnvemrwvn wrote: post #47
oblio wrote: post #5

Earlier quoted context omitted.

They kind of made several plugins "blessed": Pipeline, Blue Ocean, Git, etc. The core package plus these "blessed" plugins is a lot more stable than throwing every random plugin on top of a base installation. Just write a bit of glue script code and you're golden.

They still have their own issues. Blue Ocean requires a lot of stuff I have no need for (like github support) which in some cases conflict with stuff I do need (like bitbucket support)

Same. Every time there's a Blue Ocean update it requires you to update two dozens other plugins, many of which I don't use and can't get rid of (like the github one). And more annoying is the fact that you can't "select all" to update all plugins, you have to select them one by one.

Re: Shifting Gears

#64

Post by foobarian »

TremendousJudge wrote: post #13
victorin wrote: post #3

Earlier quoted context omitted.

Agree. The same happened with Eclipse IDE

And Firefox to some extent, except they actually fixed it by requiring all addons to be reimplemented. Lesser of two evils and all that

Less related but Minecraft servers were also a plugin mess. With N plugins, similar odds for any given plugin to break across an update, and frequent updates you'd pretty much always have broken plugins.

Re: Shifting Gears

#65

Post by zippie »

sytse wrote: post #30
chinhodado wrote: post #2

Jenkins's biggest strength is also its biggest weakness: plugins. Any development shop that has been using Jenkins for a while is using at least a bunch of plugins. Plugins are not stable, they break every now and then. They require constant update with new Jenkins versions. They get abandoned by their creators (hell, many plugins still don't support pipeline). It's a fundamental issue with how Jenkins is set up that…

I agree this weakness comes from plugins. Because the plugins are not part of the main code base you can't introduce new functionality without breaking them. So you end up with a slow pace of development while you still end up breaking installations on upgrade. If you add functionality to the main codebase you can keep running your tests to ensure nothing breaks. This is what I think they will do with Cloud Native Je…

Thank you for all the work on GitLab, we are using AutoDevops extensively. Any thoughts on how AD morphs or adapts with knative? It seems like Jenkins is fully knative with CRD support.

Re: Shifting Gears

#66

Post by sytse »

zippie wrote: post #65
sytse wrote: post #30

Earlier quoted context omitted.

I agree this weakness comes from plugins. Because the plugins are not part of the main code base you can't introduce new functionality without breaking them. So you end up with a slow pace of development while you still end up breaking installations on upgrade. If you add functionality to the main codebase you can keep running your tests to ensure nothing breaks. This is what I think they will do with Cloud Native Je…

Thank you for all the work on GitLab, we are using AutoDevops extensively. Any thoughts on how AD morphs or adapts with knative? It seems like Jenkins is fully knative with CRD support.

You're welcome, thanks for commenting. Auto DevOps can probably benefit from Knative in two ways. Use Knative build https://github.com/knative/docs/blob/master/build/builder-co... for building images. And use Knative serving https://github.com/knative/serving to run review apps that don't use resources when not in use https://gitlab.com/gitlab-org/gitlab-ee/issues/3585#note_900...

Re: Shifting Gears

#67

Post by jacques_chester »

twic wrote: post #32
cfontes wrote: post #15

Nice to know there is a plan and it's refreshing to see that they can understand most of the problems from the customer perspective now. I hope they address the constant shifts in focus with this plan and Jenkins can secure it's market spot, it really deserves it from a historical point of view in the least. It should not be a Nokia or a Xerox, it's better than that and has been a major tool for the industry. The who…

First i've heard of Argo CI. Why would i want that rather than Concourse? Which can now be deployed on Kubernetes, it seems: https://github.com/helm/charts/tree/master/stable/concourse

Concourse's components (ATC, DB, Workers) can run on Kubernetes, but it is still handling the scheduling of containers it creates.

Delegating container scheduling to Kubernetes is the next major epic on the Core track for Concourse.

As for Argo: I am not particularly in favour of Turing-complete YAML.

Disclosure: I really like Concourse. I work for Pivotal, which sponsors Concourse development.

Re: Shifting Gears

#68

Post by cfontes »

twic wrote: post #32
cfontes wrote: post #15

Nice to know there is a plan and it's refreshing to see that they can understand most of the problems from the customer perspective now. I hope they address the constant shifts in focus with this plan and Jenkins can secure it's market spot, it really deserves it from a historical point of view in the least. It should not be a Nokia or a Xerox, it's better than that and has been a major tool for the industry. The who…

First i've heard of Argo CI. Why would i want that rather than Concourse? Which can now be deployed on Kubernetes, it seems: https://github.com/helm/charts/tree/master/stable/concourse

I am no Concourse expert, but I've tried it a couple times.

Concourse's interface is just beautiful and functional, the CLI is great as well, but it has it's own ecosystem. Lot's of tools to solve problems that K8s already solves (Jobs, Volumes, resources, scheduling, etc..) it also uses workers which if I remember correctly is just like a scheduled slave which you need to install stuff into.

Argo is a different beast, it uses k8s like it should be done in my view.

It schedules container to one or multiple k8s Clusters, using CRDs which is kind of a DSL on top of the k8s api. It does not run slaves, is simply a debian or busybox pod, a Job or other resource that runs and returns pakages to the workflow or pass it on. The Syntax, is K8S YAML syntax, the same with a couple more things, very little learning curve if you know K8S YAMLs, Concourse is a very different thing.

BTW I have zero to do with Argo, I just find it awesome and am waiting for it to be more stable.

Re: Shifting Gears

#69

Post by rosshemsley »

I was seduced by BlueOcean and tried using Jenkins for CI, using Github and AWS ECS builders (which felt like a common enough use-case).

Unfortunately it ended up costing an astonishing amount of engineering time to get working and maintain, with builds frequently stalled or failing.

Since moving to CircleCI 2.0 enterprise (admittedly far from perfect) and Airflow, we have _dramatically_ reduced eng. time spent managing our job scheduling.

The core of our problem was how fragile and complex the Jenkins ecosystem seems to be: any change to the config or settings and it would easily burn a day of engineering, due to random bugs and hard to understand error messages. In the end, no one wanted to touch it!

I think there's a great project hidden somewhere here, but just getting the basic "everyday" stuff done with it can be a real PITA.

Re: Shifting Gears

#70

Post by jacques_chester »

chinhodado wrote: post #2

Jenkins's biggest strength is also its biggest weakness: plugins. Any development shop that has been using Jenkins for a while is using at least a bunch of plugins. Plugins are not stable, they break every now and then. They require constant update with new Jenkins versions. They get abandoned by their creators (hell, many plugins still don't support pipeline). It's a fundamental issue with how Jenkins is set up that…

The deeper issue with plugins is that they create global state across everything.

Switching the execution engine to Kubernetes will help a lot with operational pain. But consider the comparison to Concourse, which also predates Kubernetes. What drove Concourse into being wasn't the lack of Kubernetes (being born during the Diego project, itself a container scheduler), it was the amount of time and pain and unsafety that came from relying on the status quo.

Kawaguchi's agenda is bold and necessary, but I think it's going to take a while to get through even half of it. But the world is better off when Jenkins improves, simply because of its phenomenal installation base. We all talk about Travis and Circle and Drone and Concourse and Gitlab here, but I would bet folding money that over 75% of actual bits going through CI are going through some version of Jenkins.

Disclosure: I work for Pivotal, we sponsor Concourse.

Post reply on HN