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

Untangling Jenkins

conjur.org

Post reply on HN
Print view View original

21–30 of 53 posts

Re: Untangling Jenkins

#21

Post by Someone »

BlanketApple wrote: post #5

Man, I'm having this problem right now at work and it's been a nightmare. Admittedly the problem is like 90% cultural. People (on my team) don't understand pipeline and they absolutely don't understand Groovy. Before, they would just write a job with a shell script that e.g. ran valgrind, etc. Lots of small repos with similar steps, so they'd write one job and apply it to 20 different repos. It worked pretty well. Th…

”It's also just a bit of an organizational nightmare to see 200+ jobs on the main screen”

I never look at the main screen. You can create tabs that segment those 200 jobs. If your job names are consistent (as they should), you can do the segmenting by regular expression (I’m not sure whether creating tabs requires a plug-in)

As to doing (almost) the same thing for different projects: you can POST XML job definitions to the web interface, so if you have the rights to create jobs and to run code on your local system, you can script job creation. In my experience, that’s the way to keep job definitions consistent. To figure out what the XML to POST should look like, grab it from your browser by GETting job/jobname/config.xml (https://support.cloudbees.com/hc/en-us/articles/218353308-Ho...)

Yes, that duplicates lots of stuff in the Jenkins job definitions, but you shouldn’t treat that as source, but as the output of your job creation scripts.

Re: Untangling Jenkins

#24

Post by chrisanthropic »

The best Jenkins advice I ever received was from here: https://medium.com/mindera/jenkins-a-la-travis-6c5a8debbb5b

On setting up Jenkins Job Builder using a 'seed job'. This setup allows you to add a .jenkins directory to you project, define a yaml based jenkins job inside that directory, push to github, and Jenkins will create the job you defined - NO web UI required.

In other words you make Jenkins behave like Travis.

Set this up with your first job being a job to backup Jenkins to S3 and things aren't as bad to manage.

Re: Untangling Jenkins

#25

Post by tokenizerrr »

Someone wrote: post #21
BlanketApple wrote: post #5

Man, I'm having this problem right now at work and it's been a nightmare. Admittedly the problem is like 90% cultural. People (on my team) don't understand pipeline and they absolutely don't understand Groovy. Before, they would just write a job with a shell script that e.g. ran valgrind, etc. Lots of small repos with similar steps, so they'd write one job and apply it to 20 different repos. It worked pretty well. Th…

”It's also just a bit of an organizational nightmare to see 200+ jobs on the main screen” I never look at the main screen. You can create tabs that segment those 200 jobs. If your job names are consistent (as they should), you can do the segmenting by regular expression (I’m not sure whether creating tabs requires a plug-in) As to doing (almost) the same thing for different projects: you can POST XML job definitions…

If you get to that point, check out the Job DSL plugin.

Re: Untangling Jenkins

#26

Post by grogenaut »

BlanketApple wrote: post #14
grogenaut wrote: post #13

Earlier quoted context omitted.

Why not make it easy to reuse functions to do the steps the groovy is doing and build all of the common steps in a reusable way? Eg what the article is suggesting

Yeah, we've done that. And again, this is totally a cultural problem. But inevitably I end up writing that shared groovy code (because I have the most familiarity), and so when things go wrong, or it needs to be changed, I end up being the one having to debug it. Definitely a huge bus factor. It'd be nice if it was a slightly more common language (e.g. Python) so it wasn't such a pain.

Aah. Cultural problems are different. What's the main issue there?

Making a Python language plugin wouldn't be hard though.

Re: Untangling Jenkins

#27

Post by infamousjoeg »

mikewhy wrote: post #16
correlation wrote: post #6

I have come up with a slogan for Jenkins: "Jenkins - The butler that does not hesitate to do a disservice". It is currently the most brittle piece of infrastructure we run, with jobs spiralling out of control and slaves crashing with cryptic exceptions. Add to that a horrible plugin ecosystem (tried to install the Slack plugin, it crashed all builds and our webhook endpoint). Add to that groovy (I don't feel like bec…

We use Gitlab's built in CI and it's been a dream. Pipelines, Docker, artifacts, caching, coverage, in-repo config, Windows/macOS/Linux.

You're not the first I've heard going this route... +1

Re: Untangling Jenkins

#28

Post by emmelaich »

mikewhy wrote: post #17
oblio wrote: post #2

I've been a build/release engineer for quite a few years now, most spent using Jenkins. It can be quite a heavyweight beast, especially since it's written in Java (so heavy in terms of resource usage) and since it's old (so lots of legacy in terms of architecture). Still, in terms of costs and scalability (up to the level where you have thousands of developers and you probably want to roll your own), I think it is on…

Another downside to Jenkins: $200/hr to learn other products do it just as well with much less overhead.

I think $200/h is a low-end average estimate for any type of enterprisey software, open source or not.

If you don't buy expertise in the short term, it may cost you a lot more in the long run.

Re: Untangling Jenkins

#29

Post by emmelaich »

tokenizerrr wrote: post #23
emmelaich wrote: post #20

Has anyone here used BlueOcean and have anything to say about it good or bad? https://jenkins.io/projects/blueocean/

Meh. The interface for viewing logs lags my browser.

It is beta-ish still, so that may go away. I was more looking for comments about the features, pipeline etc.

Also, regarding logs the site says this:

"Diagnose problems instantly and say good-riddance to endlessly scanning through logs."

Won't believe till I try it but it's a good goal!

Re: Untangling Jenkins

#30

Post by nunez »

Jenkins and any other CI/CD tool is a prime candidate for immutable infrastructure; it’s the one thing that nobody cares about too much until it no longer works, and it is relatively easy to get going with scripts or Docker
Post reply on HN