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

51–60 of 123 posts

Re: Shifting Gears

#51

Post by csanchez »

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

you can fetch the credentials from Kubernetes secrets using this plugin https://jenkinsci.github.io/kubernetes-credentials-provider-... and manage both your Ops and Jenkins credentials the same way

Re: Shifting Gears

#52

Post by jstrachan »

bdcravens wrote: post #28

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.

even from an OSS goals perspective I'm looking forward to seeing better alignment, reuse and interoperability between Jenkins, Jenkins X & things like CodeShip & Knative Build

Re: Shifting Gears

#53

Post by jstrachan »

lima wrote: post #4

OpenShift's Jenkins Kubernetes integration plugin is pretty neat. Authentication, SSH secrets and - most importantly - running each build in an ephemeral pod works out of the box. https://docs.openshift.com/container-platform/3.9/dev_guide/...

OpenShift's Jenkins integration is good.

Though its even cooler to use Jenkins X on OpenShift as you get automated CI/CD pipelines + Environments, Preview Environments on Pull Requests and GitOps based Promotion between environments.

Re: Shifting Gears

#55

Post by [deleted] »

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

[deleted]

Re: Shifting Gears

#56

Post by sytse »

Boxxed wrote: post #36
dsumenkovic wrote: post #11

Earlier quoted context omitted.

Glad to hear that. We'd love to hear your feedback about GitLab CI/CD.

Last I used Gitlab CI I remember being somewhat infuriated at the fact that I couldn't use the Gitlab docker repo as the source for my build images. That was about a year ago though so that might be old news.

Not sure I understand your request but you can use docker images as part of your build https://docs.gitlab.com/ee/ci/docker/using_docker_images.htm...

Re: Shifting Gears

#57

Post by mooreds »

oblio wrote: post #20
Aissen wrote: post #16

I'm surprised they have such a good understanding of Jenkins' shortcomings. It's a good first step in fixing them. Although to be fair, this has been coming a long time as the post says; but having Cloudbees' CTO publicly acknowledging those is even better.

He's not only Cloudbees CTO, he's the original developer and architect. And before someone lambasts him for the Jenkins architecture, Jenkins/Hudson was created in 2005, when things were a lot different, and Jenkins managed to create an entire subgenre of software and lead it to the current day. Jenkins hasn't aged gracefully but how many software products from any category have even survived 5 or 10 years? :)

I can think of a number (Linux, Eclipse, vim, mysql, etc), but as a percentage of total software produced, it's very small.

Re: Shifting Gears

#58

Post by jonthepirate »

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 for all of the Jenkins behaviors that are useful for each of our microservices, implemented a Flask app that receives each of the GitHub webhooks which starts pipelines instantly (rather than git polling), setup Okta integration, interfaced with our internal secrets store, and implemented a way to map GitHub users to Slack users allowing us to Slack message people when they are mentioned in GitHub (when their PR's receive LGTM's etc.) When new microservices launch, Folders automatically appear in Jenkins configured correctly for the service's pipelines.

If any of this sounds good let me know, maybe we open source some of our work. I love working on Jenkins and am happy to help advise you on how to scale, secure, demystify your own Jenkins setup. Links on my HN profile page.

Re: Shifting Gears

#59

Post by [deleted] »

oblio wrote: post #20
Aissen wrote: post #16

I'm surprised they have such a good understanding of Jenkins' shortcomings. It's a good first step in fixing them. Although to be fair, this has been coming a long time as the post says; but having Cloudbees' CTO publicly acknowledging those is even better.

He's not only Cloudbees CTO, he's the original developer and architect. And before someone lambasts him for the Jenkins architecture, Jenkins/Hudson was created in 2005, when things were a lot different, and Jenkins managed to create an entire subgenre of software and lead it to the current day. Jenkins hasn't aged gracefully but how many software products from any category have even survived 5 or 10 years? :)

[deleted]

Re: Shifting Gears

#60

Post by tmaczukin »

Boxxed wrote: post #36
dsumenkovic wrote: post #11

Earlier quoted context omitted.

Glad to hear that. We'd love to hear your feedback about GitLab CI/CD.

Last I used Gitlab CI I remember being somewhat infuriated at the fact that I couldn't use the Gitlab docker repo as the source for my build images. That was about a year ago though so that might be old news.

You can use images hosted on GitLab's Container Registry. Especially - you can use such images as the base for CI/CD jobs running on the same GitLab instance.

It was possible since very erly state of GitLab's Container Registry. The problem was when one wanted to use images created from internal or private projects, which require previous authentication. Support for such workflow was added (partially) in GitLab Runner 0.6, and with GitLab Runner 1.8 (late 2016) it's possible to use any private registry with GitLab CI jobs. And private images from the same GitLab instance are accessible without any additional work that needs to be made by the user - until the user who triggered a job has access to the project where requested image is stored.

Details can be found at https://docs.gitlab.com/ee/ci/docker/using_docker_images.htm....

Post reply on HN