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

31–40 of 123 posts

Re: Shifting Gears

#31

Post by 0x8BADF00D »

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

Unfortunately, it’s not very easy to do. If you want syntax validation, you can validate it by POSTing to an endpoint on your Jenkins master.

If you want a “sandbox”, you can just replay a pipeline run and make modifications. Both are not very useful IMO and slow down development pace substantially. Don’t get me started on integrating groovy shared libs.

Re: Shifting Gears

#32

Post by twic »

cfontes wrote: post #15

Nice to know there is a plan and it's refreshing to see that they can understand most of the problems from the customer perspective now. I hope they address the constant shifts in focus with this plan and Jenkins can secure it's market spot, it really deserves it from a historical point of view in the least. It should not be a Nokia or a Xerox, it's better than that and has been a major tool for the industry. The who…

First i've heard of Argo CI. Why would i want that rather than Concourse? Which can now be deployed on Kubernetes, it seems:

https://github.com/helm/charts/tree/master/stable/concourse

Re: Shifting Gears

#33

Post by tannhaeuser »

I'm wishing Jenkins all the best. I know it since the Hudson times as the de-facto CI system for Java (and Cruise Control before that as my first encounter with CI).

OT: does anybody know a CI system based on plain Makefiles, convention-over-configured for autotools-like default targets, and supporting file-suffix based build and test rules for C + JS + custom compilers and such?

Re: Shifting Gears

#34

Post by 0x8BADF00D »

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/...

You can just use helm to install the default chart for Jenkins, and override the specific configuration you need.

But it’s still very clunky to work with, and spinning up a pod only happens when the build queue is not empty. It’s extremely slow.

Re: Shifting Gears

#35

Post by yebyen »

sytse wrote: post #24
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…

> 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, but if it's given in the OP or somewhere else easy to find this, I'll concede it... ah... found it: > It’s not unheard of that somebody restarts Jenkins every day.)

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'm thrilled that they are making it their focus, and I'll concede also that our use of it is pretty narrow, but I haven't had these issues.

We installed it from the stable helm chart nearly 2 years ago and have hardly needed to make any tweaks. We are not tracking every K8S release, so maybe that's why I haven't noticed Jenkins falling behind, and we also haven't tried GitLab seriously (heard great things, but my work is very risk-averse when it comes to new technologies, and to be honest we rarely try new things on a short cycle once a given problem has been solved adequately for us... we are also not primarily a development shop, so maybe it makes sense.)

> The article doesn't mention how Cloud Native Jenkins addresses the problem, maybe it doesn't allow plugins.

Like I've been saying, we've always used the stable helm chart for Jenkins and started maintaining our own values.yaml about a year and a half ago. Over time we have had less need to change the templates as more configuration got moved into values.yaml. When I have needed a plugin or other configuration that is able to be set in values.yaml, that's easy and almost makes maintaining Jenkins fun. It is a little obtuse that I have to maintain my list of plugins and their latest versions there manually, but this could be something that gets resolved in Cloud-native Jenkins if they are ultimately providing an operator or something like that.

(Breaking a rule by commenting before I've read all of the content, but I liked your article and wanted to give you some feedback since you posted it.)

For configuration that doesn't live in values.yaml, Jenkins chart maintains a Persistent Volume where configuration and build artifacts/history are stored. It is easy enough to take backups of that with the ThinBackup plugin, and the storage costs of that are sure not breaking the bank.

> Services interacting through Kubernetes CRDs in order to promote better reuse and composability

And there it is! That's the big announcement from today. Knative is still early but this news from Jenkins sounds supportive and I should really read the whole article / watch the video now.

Re: Shifting Gears

#36

Post by Boxxed »

dsumenkovic wrote: post #11
Thaxll wrote: post #10

I'm trying Gitlab atm, it's great to see something simpler than Jenkins to do CI/CD.

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.

Re: Shifting Gears

#37

Post by Vinnl »

yebyen wrote: post #35
sytse wrote: post #24

Earlier quoted context omitted.

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…

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

> Is this true? Do you have a source that says this?

It's stated somewhat more strongly, but the post we're discussing itself says:

> It’s not unheard of that somebody restarts Jenkins every day.

Re: Shifting Gears

#38

Post by andbberger »

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

Same here - I really struggled to set up declarative pipelines starting out. The docs don't do a great job of distinguishing between the full groovy syntax and the new declarative syntax and there is a relative dearth of examples.

I think the swiss army knife nature of Jenkins contributes to this - there's just so much you can do.

Re: Shifting Gears

#39

Post by sytse »

yebyen wrote: post #35
sytse wrote: post #24

Earlier quoted context omitted.

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…

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

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

The OP states: "Admins today are unable to meet that heightened expectation using Jenkins easily enough. A Jenkins instance, especially a large one, requires too much overhead just to keep it running. It’s not unheard of that somebody restarts Jenkins every day."

This isn't always the case so my claim is too strong. I toned it down with https://gitlab.com/gitlab-com/www-gitlab-com/commit/672a19ca... Thanks for pointing it out!

If there is anything else I can improve in my article please let me know.

Re: Shifting Gears

#40

Post by jstrachan »

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

I think as part of the new Jenkins architecture we should be able to make it much easier to stop at a point in a pipeline & open a terminal/REPL to test out steps.

Also I'm hoping for a nice validated YAML based pipeline syntax that should make editing/validating pipelines easier

Post reply on HN