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

21–30 of 123 posts

Re: Shifting Gears

#21

Post by nrclark »

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-generator is nice, but it doesn't necessarily produce working code. Especially for things like getting secrets into a build. And it doesn't give me a broader picture for "How do I even write one of these from an empty text-box".

I recently tried the job-to-Pipeline exporter plugin, and that didn't work on my jobs - it generated stuff that didn't match the input job, and also wasn't structured like the example snippets Jenkins provides natively.

Maybe some kind of a sandbox I could experiment in? Or a REPL or something? It would really help to have something that gave great discoverability, with fast feedback. Faster than I can get by editing a job, saving it, running it, waiting, then realizing I still don't have the syntax right.

Re: Shifting Gears

#22

Post by curtis »

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.

Re: Shifting Gears

#23

Post by artursapek »

orf wrote: post #19
Rowern wrote: post #17

Earlier quoted context omitted.

I've been working with gitlab CI for the last year. Here are some of my feedbacks: - 6 months ago we seriously considered moving away because it was really unstable (even when running on private runners) but now its a lot smoother - with private runners you can have a very powerful CI without having to manage a master (as Jenkins) for a fraction of the costs (runner with docker-machine on spot instances) - beware tha…

> it will seem a good idea to run gitlab-runner on every laptop of your team to reduce cost. Will it?!

Agreed, that's a crazy way to try to reduce cost

Re: Shifting Gears

#24

Post by sytse »

mothsonasloth wrote: post #18

I think this is too much too late for Jenkins. I can't speak for other countries but in London a lot of companies are now using Gitlab or Circle CI. I migrated all my builds (12 projects) to Gitlab CI. After figuring out the first CI pipeline using DockerInDocker, it was easy to then setup the remaining pipelines. Self hosting Gitlab was perfect for our needs (private docker registry). I use Gitlab for personal use t…

Thanks for using GitLab! I'm glad to hear you found it easy to set up.

I just wrote an article in response to the OP https://about.gitlab.com/2018/09/03/how-gitlab-ci-compares-w...

We're working on making GitLab more performant. It is mostly fixes to our code, the parts where ruby is a problem are already rewritten in Go. GitLab self-hosted should be fast if it has enough memory, so make sure you check on its memory consumption.

Re: Shifting Gears

#25

Post by crazysim »

artursapek wrote: post #23
orf wrote: post #19

Earlier quoted context omitted.

> it will seem a good idea to run gitlab-runner on every laptop of your team to reduce cost. Will it?!

Agreed, that's a crazy way to try to reduce cost

Reminds me of the Xcode built-in distcc thing they had back then.

Re: Shifting Gears

#26

Post by dharmab »

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.

And the Jenkinsfile documentation is relatively bare and reliant on examples.

Re: Shifting Gears

#27

Post by honkycat »

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.

Also groovy is a bag language. Managing Jenkins pipeline library deps is a pain.

Also yeah, plugins break constantly and upgrading them is always a nightmare.

Re: Shifting Gears

#28

Post by bdcravens »

The focus on cloud-first Jenkins is interesting considering Codebees's acquisition of Codeship earlier this year. Obviously Kohsuke would be biased to Jenkins, but as CTO, I'd imagine the corporate goals take precedence.

Re: Shifting Gears

#29

Post by twic »

mothsonasloth wrote: post #18

I think this is too much too late for Jenkins. I can't speak for other countries but in London a lot of companies are now using Gitlab or Circle CI. I migrated all my builds (12 projects) to Gitlab CI. After figuring out the first CI pipeline using DockerInDocker, it was easy to then setup the remaining pipelines. Self hosting Gitlab was perfect for our needs (private docker registry). I use Gitlab for personal use t…

"in London" suggests that geography is the primary driver of your first-hand experience, rather than tech stack or company type. I've been working in London for a decade, and i don't think i've ever used either Gitlab or CircleCI for CI!

That said, i haven't used Jenkins for several years either.

Re: Shifting Gears

#30

Post by sytse »

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 Jenkins. Essentially abandoning plugins.

Jenkins Evergreen keeps only the essential plugins. This means they can run better tests. And when introducing new functionality you can update the essential plugins.

With GitLab CI we add new functionality in the main code base, avoiding the need for needless configuration and ensuring everything still works when updating.

I have just written a more extensive analysis of the blog post in https://about.gitlab.com/2018/09/03/how-gitlab-ci-compares-w...

Post reply on HN