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

Jenkins pipelines as YAML

jenkins.io

Post reply on HN
Print view View original

41–50 of 76 posts

Re: Jenkins pipelines as YAML

#41

Post by lomnakkus »

twblalock wrote: post #36
rollulus wrote: post #28

I'm wondering, who uses Jenkins nowadays and why? A few years ago, at one of my first gigs in an enterprise environment, I used Jenkins for the first time to test and build my stuff. When I needed a newer version of my compiler or specific linter, some fellow had to install that on the VM that was running Jenkins. Later, working in a more modern environment, we started using Gitlab CI. It was a bliss. I specified the…

> At my current gig, again an enterprise, it is Jenkins everywhere. They do the most complex things with it, orchestrating entire releases, integration tests, etc. You just answered your own question -- people use Jenkins because it can do all of those things.

It's possible to use Jenkins to do all of those things. It's also enormously costly in terms of manpower, etc.

It's truly absurd just how much shepherding Jenkins requires once you have build slaves, etc. The pipeline stuff is heaps better, but unfortunately it doesn't really work for the workflow we're using in our shop, so... sad faces all round :(.

Re: Jenkins pipelines as YAML

#42

Post by KaiserPro »

Chico75 wrote: post #12

This is just lowering themselves to the same level as every other CI tool. For sure YAML is an easier barrier to entry to overcome, but it's also a low ceiling. YAML doesn't let you transcribe logic easily compared to any programming language, and build logic always tends to go up. Programming languages also allows you to create abstraction to remove some of the complexity from the users.

"This is just lowering themselves to the same level as every other CI tool" you mean making a stable simple and repeatable interface that can be saved in source control?

Re: Jenkins pipelines as YAML

#43

Post by mart187 »

We have Jenkins connected to ECS as build agent pool. Every team has it's own Jenkins instance running, secured with AD login. Pipelines are using Jenkinsfiles. My only critique is that it's not fully ci as code because you need to manually create the pipeline, connect it to fit repo, etc.

Re: Jenkins pipelines as YAML

#44

Post by KaiserPro »

rollulus wrote: post #28

I'm wondering, who uses Jenkins nowadays and why? A few years ago, at one of my first gigs in an enterprise environment, I used Jenkins for the first time to test and build my stuff. When I needed a newer version of my compiler or specific linter, some fellow had to install that on the VM that was running Jenkins. Later, working in a more modern environment, we started using Gitlab CI. It was a bliss. I specified the…

We use it because of legacy. Its fragile, un-updatable and virtually un-automatable. Use plugins? They'll break. Use JJB to make things repeatable? Someone has made a change in the GUI. At last count we had something like 70+ jenkins masters (because we couldn't share slaves, because people kept on cocking up the master.)

The rise of circle-CI style yaml interface is wonderful. The build script is there in the repo, for all to see. Yes, there is less logic, but that's a good thing. Build, test, deploy, alert if fail.

Gitlab's runner is also good. (just don't use the Saas version, as the only thing it does well is downtime.)

Re: Jenkins pipelines as YAML

#45

Post by quacker »

rhencke wrote: post #24
zdw wrote: post #3

Looks interesting, although it seems very similar to another project, Jenkins Job Builder ( https://docs.openstack.org/infra/jenkins-job-builder/ ) that can describe jobs as YAML or JSON, and is designed one level higher as a meta-jobs creator that can create many jobs all with slight variations, with all of the config kept in version control (no manual fiddling with the Jenkins GUI, other than troubleshooting). With…

Also highly recommended is Jenkins Job DSL, which, despite also using Groovy like Jenkins Pipeline, takes a far different approach. In Job DSL, you write Groovy scripts to declare your job. These scripts, in turn, write the config.xml that Jenkins uses to actually define and execute jobs. One of the big benefits to us is that it is _not_ an alternate execution engine like Jenkins Pipeline is. It just takes over the j…

Just to add, Jenkins Job Builder supports configuring jobs that use the Job DSL plugin[1] in addition to a variety of other ways to configure jobs.

1. https://docs.openstack.org/infra/jenkins-job-builder/builder...

Re: Jenkins pipelines as YAML

#46

Post by fatninja »

moduspol wrote: post #34
rollulus wrote: post #28

I'm wondering, who uses Jenkins nowadays and why? A few years ago, at one of my first gigs in an enterprise environment, I used Jenkins for the first time to test and build my stuff. When I needed a newer version of my compiler or specific linter, some fellow had to install that on the VM that was running Jenkins. Later, working in a more modern environment, we started using Gitlab CI. It was a bliss. I specified the…

We're using it because it costs nothing and it's what everyone already knows. We're making a big architectural shift to microservices and I made a pitch for the Travis / CircleCI style workflow, but after Jenkins pipelines were discovered, that was the compromise that was made. We've only got our toes in it now, but from what it looks like, you theoretically can use a Jenkins pipeline (with a Jenkinsfile) to get some…

>> our Jenkinsfile can assume certain plugins are installed, assume other jobs are configured on the same Jenkins

I think what worked for us in this case was using Jenkins shared library[1]. We provide a common template for the common stacks and expose only few configurable options. This would really help in maintaining sanity across the jenkins env and since you maintain the shared lib, you can control the dependencies.

[1] - https://jenkins.io/doc/book/pipeline/shared-libraries/

Re: Jenkins pipelines as YAML

#48

Post by chucky_z »

mart187 wrote: post #43

We have Jenkins connected to ECS as build agent pool. Every team has it's own Jenkins instance running, secured with AD login. Pipelines are using Jenkinsfiles. My only critique is that it's not fully ci as code because you need to manually create the pipeline, connect it to fit repo, etc.

Have you looked into https://wiki.jenkins.io/display/JENKINS/Groovy+Hook+Script ?

There's a handful of cool scripts that other folks have written :)

Check out this repo for an example: https://github.com/hayderimran7/useful-jenkins-groovy-init-s...

Re: Jenkins pipelines as YAML

#50

Post by brightball »

rollulus wrote: post #28

I'm wondering, who uses Jenkins nowadays and why? A few years ago, at one of my first gigs in an enterprise environment, I used Jenkins for the first time to test and build my stuff. When I needed a newer version of my compiler or specific linter, some fellow had to install that on the VM that was running Jenkins. Later, working in a more modern environment, we started using Gitlab CI. It was a bliss. I specified the…

The biggest thing is that Jenkins isn't a CI tool, it's a job execution tool. Whether those jobs are scheduled, manually triggered, triggered by a webhook or otherwise..that's it. It runs the job, records the output and the exit status and makes it easy to read the log of any of those jobs, as well as alternating log rotation of them. It can also manage multiple nodes, distribute those jobs across them or isolate certain jobs to certain nodes.

All that a CI server does is run install dependencies, run the job and then do something with the output. There are tons of plugins for Jenkins to handle those specialized bits of output.

If you want to use Docker images for it, you can do that. If you want to use it to run cron jobs across multiple servers over SSH but centralize the logging and error notification...you can do that. If you want to schedule scaling jobs for expected traffic...you can do that. If you want to trigger Ansible execution...you can do that.

Trigger, Run, Track, Parse. Jenkins does it general purpose, for free, with flexibility to handle many different types of work and different auth tools in one place.

The UI could be better...but it's also hard to tune the UI unless you are specialized for a certain type of work.

The real question is...why bother with a special CI-only tool when you can use Jenkins for that and a whole lot more?

Post reply on HN