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

91–100 of 123 posts

Re: Shifting Gears

#91

Post by geerlingguy »

chinhodado wrote: post #63
isbvhodnvemrwvn wrote: post #47

Earlier quoted context omitted.

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.

There’s a select all link at the bottom of the plugin updates page...

Re: Shifting Gears

#92

Post by michaelneale »

jonthepirate wrote: post #58

I worked on Jenkins at Lyft and completely set it up for DoorDash. If anybody needs help with their Jenkins setup, hit me up I give free advice and have a few blog posts on the matter. If you happen to be using AWS, GitHub, and Slack, we at DoorDash have developed lots of goodies for streamlining things. We have secured our Jenkins behind our VPN, created load balanced Jenkins clusters, built a shared Groovy library…

Glad to hear that - you should put your config up on a blog post somewhere sometime.

Re: Shifting Gears

#93

Post by michaelneale »

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…

Part of the ideas mentioned are to resolve this stability, and not depend on in process plugins (a new extensibility architecture that won't hurt stability). There are many things in plugins which should be core functionality (and will be).

Re: Shifting Gears

#94

Post by michaelneale »

chinhodado wrote: post #63
isbvhodnvemrwvn wrote: post #47

Earlier quoted context omitted.

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.

well glad to see people using blue ocean, but yeah - that isn't a good look (and one of the aims mentioned is to get away from this pain, for good).

(also evergreen should take care of the updating, ideally). I will be happy when it does as don't want to spend any more time thinking about this!

Re: Shifting Gears

#95

Post by michaelneale »

jacques_chester wrote: post #82
yebyen wrote: post #35

Earlier quoted context omitted.

> The current legacy version of Jenkins needs to be restarted once a day by an administrator Is this true? Do you have a source that says this? We have a Jenkins instance that Kubernetes is configured to scale down from 1 replica to 0 at night, and up to 1 again in the morning, so if it is true we never would have noticed. (It hasn't always run on this cron cycle, which is why I'm a little incredulous at this claim,…

> Honestly I don't understand this about "making a version of Jenkins that runs well on Kubernetes" – this is the _only way_ I have ever run Jenkins, and I think it runs already extraordinarily well for our purposes. I think the idea is not that Jenkins runs on Kubernetes, which as you note can already be done. It's rather that Jenkins uses Kubernetes as a replacement for the worker infrastructure.

yes that is right I believe.

Re: Shifting Gears

#96

Post by liveoneggs »

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

secrets are scoped and the snippet generator will put in the correct GUID (or whatever that id is) for you.

Re: Shifting Gears

#97

Post by jacques_chester »

twic wrote: post #87
jacques_chester wrote: post #67

Earlier quoted context omitted.

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.

Wait, doesn't Pivotal also sponsor Turing-complete YAML development?

BOSH v1 manifests were Lovecraftian. Well beyond Turing and into the deep underdark of the Beyondness That Must Not Be Yea Even Unto Enterprise.

Re: Shifting Gears

#98

Post by Sir_Cmpwn »

ak217 wrote: post #88

Having used Hudson/Jenkins for many years, I recently considered setting it up for a new project, and backed away mostly due to the issues Kohsuke describes. We ended up choosing GitLab instead. GitLab has been pulling ahead in features and usability, compared to other things I've tried. Right now, different projects I'm involved with use a combination of GitLab Enterprise, Travis, Circle, and Google Cloud Build. Of…

If you don't mind, I'll shill my service as another option: builds.sr.ht. It's still in closed alpha, but it's being used seriously by several open-source projects for complex build automation. It also deploys itself, here's the build manifest which does it:

https://git.sr.ht/~sircmpwn/builds.sr.ht/tree/.build.yml

And an example of a build which used it:

https://builds.sr.ht/~sircmpwn/job/6974

If you or anyone else would like to try it, please let me know. I used Jenkins for a long time (and still do at work), Travis for a while as well, also tried Drone and Circle, but none of them were exactly right. I think builds.sr.ht does it very well.

Re: Shifting Gears

#99

Post by twistadias »

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…

I am in London, and our firm uses Jenkins on a huge scale. Certain industries won’t touch products that can’t be installed on premise.

Re: Shifting Gears

#100

Post by baylisscg »

At ${DayJob} Jenkins is our default of yore. Returning to refresh a 1.x install for one group's product we're faced with the poster child for a Jenkins install gone bad. Looking at you Chuck Norris plugin. We can't upgrade and we can't migrate to a fresh install due to how Jenkins handles plugins. So we're left with a critical chunk of infrastructure that's a time bomb.

Ultimately instead of making the jump to 2.x and Jenkinsfiles we're trialing Buildkite with great success so far and the confidence that we can jump ship to CloudBuild, TravisCI, Concourse, CircleCI, ect should we need to.

Post reply on HN