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

Jenkins Is Getting Old

itnext.io

Post reply on HN
Print view View original

221–230 of 340 posts

Re: Jenkins Is Getting Old

#221

Post by chucky_z »

michaelneale wrote: post #145
KaiserPro wrote: post #95

I have been with jenkins since about 2010. At its peak I had to shepherd ~50 masters of varying ages, plugins and levels of customisations. Yes, it allowed repeatable builds, and it can be, in certain circumstances a very good replacement for cron jobs where you need to administer >5000 machines. However, it has an offensive UI, the plugin system appears to be designed to deliberately cause things to break, versionin…

I think this "lesson" is not lost on many, including those that built and work with Jenkins and plugins. The Jenkins X project moved to a very different approach, a fresh start. see https://cd.foundation/ & https://jenkins-x.io (it works with Jenkins if you like, but natively uses the new pipelines and no SPOF masters). Might not be for everyone but worth a look. disclosure: cofounder of cloudbees here (wanted to com…

Why the dependence on Kubernetes everywhere in these new tools?

Re: Jenkins Is Getting Old

#222

Post by sudofail »

bogomipz wrote: post #182
sudofail wrote: post #100

What I'd like to see is a CI/CD engine backend. Most CI/CD solutions have relatively the same feature set: - Code builds - Code deploys - Git Hooks - Parallel builds - Matrix builds - Build as configuration - Etc If there were an engine that supported these features, the community could create a number of frontends that target their specific needs. Jenkins was held back, in my opinion, for a number of years by its an…

What is a "matrix build" in the context of CI/CD?

When your software needs to build on, or run on multiple targets, it's useful to define it in a matrix. Here's an example: https://0-8-0.docs.drone.io/matrix-builds/

Re: Jenkins Is Getting Old

#223

Post by tedk-42 »

agentx3r wrote: post #109
sanitz wrote: post #61

I recommend https://concourse-ci.org/

I really love the ideas/architecture behind Concourse, but there's a few things that disqualified it in favour of Jenkins for a new CI pipeline during prototyping: - no hooks to manage worker scaling ( https://github.com/concourse/concourse/issues/993 ). Our builds are _heavy_ and we'd run up an enormous AWS bill without something like ( https://wiki.jenkins.io/display/JENKINS/Amazon+EC2+Plugin ) - no way to restart…

Wow I never knew Jenkins could scale its workers like that. We definitely have performance issues with our Concourse cluster running in K8s. It's got it's own set of dedicated nodes but we need to scale the workers better as they're ofter under heavy load throughout the day when the devs are pushing code and a bunch of tests are running in Concourse (and PR checks as well)!

Concourse definitely feels more refined than Jenkins. Like other commenters have said, it's a steep learning curve to grasp how things move between Tasks/Jobs.

Re: Jenkins Is Getting Old

#224

Post by donmcronald »

nhumrich wrote: post #206
badloginagain wrote: post #113

Earlier quoted context omitted.

GitLab CI is pretty good. I hate, on a fundamental level this whole "bash in YAML" trend. Let's take a powerful, turing complete language and put it in a _config file_. What? I don't even... And the fact that you only get _one_ .gitlab-ci.yml file. That is legitimate madness. Want modularized CI/CD configuration? Not in these parts, buster. Have submodule build dependencies? We laugh at your use case. Sure as shit be…

Gitlab lets you run any step with a different docker base image. How about instead of bash scripting in the yaml, you just put scripts, in any language, in a docket file, and simply use bash to call those scripts. The gitlab yaml is not designed for you to code in, bash is just a standard interface for calling into other things.

This is what I’ve been doing lately. It has the advantage of being able to run the scripts without GitLab CI.

Re: Jenkins Is Getting Old

#225

Post by asey »

asgeirn wrote: post #12

Our setup runs Jenkins master and slaves as Kubernetes pods, with plugins limited to only the very few required to get GitHub integration and slaves working. Jobs are configured by adding an entire GitHub organization. All repositories with corresponding branches, pull requests and tags are automatically discovered and built based on the existence of a Jenkinsfile. Everything is built by slaves using Docker, either w…

That is exactly how we're doing it as well, though I am interested in checking out Cloudbees'Jenkins. We've recently incorporated Zalenium (selenium grid which autoscales nicely natively in kubernetes) - just had to work a little magic with automatic service creation during builds.

Re: Jenkins Is Getting Old

#226

Post by cpitman »

chinhodado wrote: post #199
saidmasoud wrote: post #153

Earlier quoted context omitted.

2) was released in October, about six months ago [0]. I'd also like to add: as a user of GitLab for about a year now, their steady rate of feature releases has bene pretty pleasant, even if I can't take advantage of some right away. [0] https://about.gitlab.com/2018/10/22/gitlab-11-4-released/#ru...

I'm not sure that's what I needed. For example, I wanted to trigger a job only for a merge request, and only if the target branch of the merge request is e.g. master. Is that possible? Trigger a job only for a MR is possible, but I don't know how to further do the later branch filtering.

When using a merge_request pipeline, GitLab defines additional variables for the run. That includes `CI_MERGE_REQUEST_TARGET_BRANCH_NAME`.

So it would look something like this:

  job:
    only:
      refs:
        - merge_requests
      variables:
        - $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"

Re: Jenkins Is Getting Old

#227

Post by blattimwind »

user5994461 wrote: post #106
orlovs wrote: post #74

Earlier quoted context omitted.

Fine, when you are one specific vendor shop, like Jetbrains or Atlassian stack and you have got plenty of financial power, then there is always cool features, what can bring benefit. But in the end CI and CD systems are glorious semi-smart cron runners. Are these tools 10x better than Jenkins. Not so much, CI/CD is from one of the standpoint most important and in the same time less important tool, delivery should suc…

Of course it can be 10 times better. It's so trivial to be 10 times better. First you checkout the project from the repo and it just works, doesn't matter GIT, SVN or whatever. How many plugins does it take to checkout a project in jenkins? Is there even a git plugin working nowadays? Then, you build the project. If it's any of C# or Java for example, the ant/maven/sln/nuget files are detected automatically, just cli…

TeamCity is indeed quite good.

Re: Jenkins Is Getting Old

#228

Post by manigandham »

orlovs wrote: post #74
user5994461 wrote: post #52

Earlier quoted context omitted.

TeamCity from JetBrains is the same thing as jenkins, except the core features are working core features instead of broken plugins. It's paid software though, you get what you pay for. https://www.jetbrains.com/teamcity/ On the other hand there is Bamboo from Atlassian. https://www.atlassian.com/software/bamboo I really don't understand this mentality of there is no better tools when there are better tools than jenki…

Fine, when you are one specific vendor shop, like Jetbrains or Atlassian stack and you have got plenty of financial power, then there is always cool features, what can bring benefit. But in the end CI and CD systems are glorious semi-smart cron runners. Are these tools 10x better than Jenkins. Not so much, CI/CD is from one of the standpoint most important and in the same time less important tool, delivery should suc…

Those tools can build anything, which is the point of a CI/CD system. There is no specific vendor you have to be invested in, it's just paid software.

Re: Jenkins Is Getting Old

#229

Post by manigandham »

michaelneale wrote: post #131

Co-founder of cloudbees here, just some corrections: 1) there are (since 1 year) restartable builds/stages in open source (a bit over a year IIRC) - when the article mentions that they are not in open source. 2) Jenkins X is something VERY DIFFERENT from Jenkins (despite the name), it is "master less", yes requires a kube cluster to power it, but it has no Jenkins instances as you know it, in a lot of ways quite a bi…

Unfortunately people are looking for simplicity and this is going in the opposite direction. A kubernetes cluster is just offloading a large part to yet another component you have to run. Spinnaker is another completely separate system.

This is the opposite of what teams want. Drone, Gitlab, Teamcity as mentioned in these comments is a far better approach for 99% of companies who want a solid working solution.

Re: Jenkins Is Getting Old

#230

Post by mattcaldwell »

balfirevic wrote: post #75
FrenchyJiby wrote: post #40

Earlier quoted context omitted.

Heyo, sorry about that, I was playing on the fact that common parlance has tamed the usage to have "TFA = The FINE Article" in civil discourse =) My bad, will check my assumptions some more!

Don't worry too much, I also thought that TFA as an abbreviation for "the fine article" is at least as well known as it is for "the fucking article".

Literally the first time I'm hearing this. :P
Post reply on HN