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

41–50 of 123 posts

Re: Shifting Gears

#41

Post by jstrachan »

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…

yeah, I see 'plugins' being around for a while but docker steps becoming the more cloud native long term alternative; being more reusable stand alone & not requiring changing a Jenkins Master (or even requiring a Jenkins master for ephemeral build pods)

Re: Shifting Gears

#42

Post by wgerard »

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-…

Yes!

Pipelines can be incredibly rewarding if you spend the time to really dig into it and do a bunch of trial-and-error.

Convincing other people on your team to do that with the current state of documentation is painful, and understandably so.

The documentation really needs a lot of attention.

Re: Shifting Gears

#43

Post by jstrachan »

curtis wrote: post #22

The biggest deficiency I found in Jenkins is that GUI-based job configuration is great for simple setups and one-off jobs, but the moment you throw in any sort of parameterization it becomes a real headache. At that point you really need to be able to configure your jobs in code.

one solution to the problem, if you are building apps for kubernetes is to use Jenkins X which automates all your CI/CD pipelines: https://jenkins-x.io/

Re: Shifting Gears

#44

Post by jstrachan »

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…

Jenkins X can help compete effectively with other tools since it automates your entire CI/CD; from creating the Pipelines, setting up your Environments, creating Preview Environments on each Pull Request and then performing GitOps based promotion through your Environments on each release.

I'm looking forward to seeing the Jenkins ecosystem expand to offer similar automated CI/CD for other platforms too (e.g. Terraform / Ansible / VMs etc)

Re: Shifting Gears

#45

Post by jstrachan »

tannhaeuser wrote: post #33

I'm wishing Jenkins all the best. I know it since the Hudson times as the de-facto CI system for Java (and Cruise Control before that as my first encounter with CI). OT: does anybody know a CI system based on plain Makefiles, convention-over-configured for autotools-like default targets, and supporting file-suffix based build and test rules for C + JS + custom compilers and such?

invoke `make` from inside your `Jenkinfile`? :)

Re: Shifting Gears

#46

Post by jstrachan »

honkycat wrote: post #27

The worst part of my job is configuring our Jenkins server and managing builds in their dumbass groovy based DSL. I'm willing to bet that most people just want to build GitHub repos. Then why do we have to do this mess to get a decently repeatable deployment strategy: https://coderanger.net/jenkins/ I should not have to crack open plugin source code in order to configure the plugin programmatically. It's dumb and bad…

if you are happy to use Kubernetes then if you switch to Jenkins X you never need to configure a Jenkins server or create a groovy based DSL again: https://jenkins-x.io/

Re: Shifting Gears

#47

Post by isbvhodnvemrwvn »

oblio wrote: post #5
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…

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)

Re: Shifting Gears

#48

Post by csanchez »

oblio wrote: post #12
mbubb wrote: post #7

I love working with Jenkins - I know it is a pain to keep up to date but for me it has become a way as a sole or small team syseng to manage all kinds of stuff. "Jenkins-Ansible-Github" where you have a Jenkinsfile sitting in the git repo you are bulding/ deploying etc., has been a pretty good set of tools to manage heterogeneous environments.

Agreed. Now if only they could generalize Configuration as Code: https://github.com/jenkinsci/configuration-as-code-plugin . It's the missing piece.

That's definitely the goal, part of Kohsuke announcement.

Re: Shifting Gears

#49

Post by jstrachan »

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

BTW we use the kubernetes credentials provider plugin in Jenkins X which exposes Kubernetes Secrets as Jenkins Credentials; then the `credentials` step in the `Jenkinsfile` encrypts them from any build logs

Re: Shifting Gears

#50

Post by isbvhodnvemrwvn »

curtis wrote: post #22

The biggest deficiency I found in Jenkins is that GUI-based job configuration is great for simple setups and one-off jobs, but the moment you throw in any sort of parameterization it becomes a real headache. At that point you really need to be able to configure your jobs in code.

jenkins-dsl does wonders in this department. When infrastructure-as-code plugin gets stable we'll have a fully immutable Jenkins setup.
Post reply on HN