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

Blue Ocean

jenkins.io

Post reply on HN
Print view View original

151–160 of 185 posts

Re: Blue Ocean

#151

Post by jacques_chester »

twic wrote: post #109
Wilya wrote: post #55

Earlier quoted context omitted.

A note on concourse deployment: their docs recommend bosh deployments, but they also provide standalone binaries [0] and the deployment workflow in this case is extremely simple. Run "concourse web" for the UI, "concourse worker" for a worker, and all the basic connectivity stuff is handled via command line parameters. That being said, depending on your company habits, the fact that concourse is very opinionated on h…

> the deployment workflow in this case is extremely simple. Run "concourse web" for the UI, "concourse worker" for a worker By which you mean, of course, "write systemd units or whatever for the web and worker jobs", because you don't want to be starting your CI system by hand. That's not rocket science, but it's not quite out of the box. That said, the emphasis on BOSH must really be hurting Concourse adoption. Nobo…

> That said, the emphasis on BOSH must really be hurting Concourse adoption.

It did, I think. My gut feel from watching the Slack chat is that lots of people are deploying using the prebuilt docker containers. There are even projects that set up k8s clusters for you.

Re: Blue Ocean

#152

Post by switchbak »

haldean wrote: post #97
Kudos wrote: post #36

Earlier quoted context omitted.

FWIW, Circle CI offers the ability to SSH in to build nodes and free nodes for public projects

...sort of. I eventually rage-quit Circle and set up a Jenkins cluster because of all of the heisenbugs we found on Circle. Builds would fail 5-10% of the time for totally unreproducible reasons (for example, pip install into a venv would fail with a permission error), and you can't SSH into a build that's already failed. We very rarely had problems with Jenkins builds, and when we did, we could go look at the enviro…

I had much the same experience. Their lack of (proper) caching support meant our already-slow build took 2.5 times as long as it should, not to mention over burdening the maven repos.

By lack of proper caching - I mean reusing a volume (or similar). They do have an approach where they bundle up some files and throw them on S3, but that can actually take more time than re-downloading them. Not much of a cache - which is important for both Docker and large Java builds.

Supposedly the v2 should fix that, but I've been waiting forever to get my beta invite.

Swapping to Jenkins allowed me to choose faster hardware, and optimize our build a bit better. Trying to get Blue Ocean to work right, but to be honest it's a supreme PITA - there seem to be bugs/undocumented workarounds in the github authorization side. Once that's up though, it _ought_ to work better.

Jenkins' usability issues are most of what's allowed these other products to become popular. Hopefully they'll focus on that a lot more, but past performance would suggest they won't. If I wasn't so lazy, I would pitch in myself :)

Re: Blue Ocean

#153

Post by mi100hael »

sytse wrote: post #147
mi100hael wrote: post #137

Earlier quoted context omitted.

I dunno, I found the opposite. Jenkins is an easy stand-alone package that I can just install & immediately navigate to the UI. GitLab-CI requires you to install & configure & link "runners" in a manner that I found less intuitive.

We're always interested in making that experience better. The reason that it is more complex than Jenkins in the first place is that we think the builds should happen on another instance than the one GitLab is running on. I've seen running the builds on the Jenkins machine lead to many problems. Hence the need for our process that we try to make easier than setting up Jenkina build slaves while still being secure whe…

Interesting, thanks for the insight. Those are certainly valid reasons for things being the way they are, but I have to wonder how many GitLab installs are like mine: a single "git/build" server on a private network serving a small group of users. I'd wager the number of installs that fall into that category is fairly substantial, and in that situation the runner configuration feels pretty over-engineered.

Re: Blue Ocean

#154

Post by alexellisuk »

pm90 wrote: post #113
alexellisuk wrote: post #104

This news is from September, I gave my first impressions on Hacker News then, here's my blog post including an interview from the team behind Blue Ocean. http://blog.alexellis.io/tag/jenkins/ They are doing a great job at reinventing JenkinsCI (but remember it's still Java)

What's wrong with Java?

Restrictive licensing and then there's the fact it is a huge memory hog. I have Blue Ocean running on a home lab with 16GB RAM and Jenkins + SSH slave drains almost all the resources.

Also - GitLab Travis / CircleCI etc being quite trendy/new remember that if you need to extend Jenkins you're dealing with a legacy product.

Re: Blue Ocean

#156

Post by pm90 »

alexellisuk wrote: post #154
pm90 wrote: post #113

Earlier quoted context omitted.

What's wrong with Java?

Restrictive licensing and then there's the fact it is a huge memory hog. I have Blue Ocean running on a home lab with 16GB RAM and Jenkins + SSH slave drains almost all the resources. Also - GitLab Travis / CircleCI etc being quite trendy/new remember that if you need to extend Jenkins you're dealing with a legacy product.

Hmm, seems like dev resources would be better spent in improving resource consumption as well. I can't imagine why it would need so much.

Re: Blue Ocean

#157

Post by vacri »

pm90 wrote: post #113
alexellisuk wrote: post #104

This news is from September, I gave my first impressions on Hacker News then, here's my blog post including an interview from the team behind Blue Ocean. http://blog.alexellis.io/tag/jenkins/ They are doing a great job at reinventing JenkinsCI (but remember it's still Java)

What's wrong with Java?

Last week I was setting up a large java app (bamboo) and I started it up. Where did I instinctively go to check that it was running? Ask systemd? No. Check the log file? Nope. I went into htop to check that the CPU was now pegged... :)

Re: Blue Ocean

#158

Post by ethangj »

tzaman wrote: post #20
knocte wrote: post #19

Earlier quoted context omitted.

IMO moving from Travis to Jenkins seems like a very disruptive change. As for me, I had used Travis just a bit, and same for Jenkins, and didn't like any of those options very much. So when my team needed to setup a CI solution, we ended up using GitLab CI, and it brings the best of both worlds: - Free service version if you use the GitLab.com deployment (granted, gitlab.com is a bit slow because it's the new thing a…

I'll definitely check it out - but the problem with many of these tools is a lack of "proper" Docker support, along with the ability to self host and debug. Thanks for the heads up!

Full disclosure, I am a Codeship employee that helps onboard new customers for our Docker support.

That said, our (Codeship) Docker support is the most "Docker native" on the market, in my opinion. We build your containers, by default, using a Compose-based syntax and all commands are natively executed by your containers. There's no interacting with a Docker host or running explicit Docker commands at all.

We don't offer self-hosting but we do have a local CLI that lets you run and debug your process locally with parity to your remote builds.

Re: Blue Ocean

#159

Post by merb »

sytse wrote: post #67
scrollaway wrote: post #41

Earlier quoted context omitted.

The problem with travis and the like is most do not support arbitrary builds. Drone for example is trying to sell itself as a "jenkins replacement" but has no concept of a build triggering arbitrarily, or that isn't intrinsically linked to a git repo. It's nonsense. Once you set up a bunch of tooling jobs on Jenkins it's very nice to be able to use it as some form of control center for a bunch of different operations…

I think there are two aspects to arbitrary builds: 1. Periodic jobs (not linked to a pushed commit) 2. Not linked to a git repo At GitLab we try to have 'infrastructure as code'. We think builds should be under version control to allow for collaboration. But periodic jobs make a lot of sense and it is discussed in https://gitlab.com/gitlab-org/gitlab-ce/issues/2989

well I know you have great idea's but sadly a lot of the focus of gitlab at the moment is either monetizing with EE (which I can understand, I need to develop for my income aswell..) and the other with adding features to CE (which of course leads to the first).

Sadly this does not fix bugs. And the issue tracker of gitlab-ce grows and grows and the CI is not really stable. The new permission model was great, but break stuff.

Unfortunatly at the moment me and my team is discussing to use gitlab + jenkins instead of gitlab + gitlab for vcs/ci. just because webhooks + jenkins is way more stable than the gitlab way (and actually webhooks are push based, while gitlab ci polls.)

This is sad since gitlab ci was quick and easy, while even the new dsl for jenkins is way harder to get right. but we actually can't retry half of our builds.

Another way would be using the shell executor where we actually loose some functionality. (we use the docker executor).

I know your vision (and I think some ideas are great), but sadly I think too much centralization is harmful after going with gitlab since v8, somethings does not need to be reinvented by gitlab (they might just need a improvement).

Re: Blue Ocean

#160

Post by scrollaway »

i386 wrote: post #52
scrollaway wrote: post #46

Earlier quoted context omitted.

Some pieces of feedback on Blue Ocean, which we've used on and off but haven't been able to switch to: - The console interface needs work. The "click on text to link to it" thing is making it very hard to select stuff. Line numbers on the left are useless for a log, timestamps would be much more useful. (Also please add ANSI color support!) - Artifacts view is awkwardly empty. Instead of the artifact name being a lin…

You're welcome and thanks so much for this feedback. There's a lot here for us to cover - would you mind if we could have a short chat over email or even a Google Hangout? My email is jdumay@cloudbees.com

Sure, sent you an email.
Post reply on HN