Live data from Hacker News

Blue Ocean

jenkins.io

101–110 of 185 posts

Re: Blue Ocean

#101
post #34

Earlier quoted context omitted.

we too found that it doesn't support all of the original jenkin's features after we tried it , and its disabled at prod .

Anything in particular you believe is missing?

The ansi output color plugin doesn't work with output. Nor the build timestamp plugin. The PR interface only works with Github, should also work with bitbucket pull requests.

And the most annoying, when blue ocean is tailing a job thats running, it uses 100% cpu on safari.

Those are the biggest issues I find with it as of today, otherwise its great for a manager mode until then.

Re: Blue Ocean

#102
post #97
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…

> (We also went from paying $1k/mo to $0/mo, which is a very nice side effect)

That's not entirely true, because someone had to set Jenkins up and has to maintain it, but once things are rolling, it hardly needs any input.

Re: Blue Ocean

#103
post #25

Earlier quoted context omitted.

Honestly my experience is that SaaS / hosted CI is just generally annoying due to constant stability and performance (both transient and in general, eg. caching in Travis) issues. Self-hosted CI on the other hand requires a lot of resources, especially when you're not only testing Linux or BSD, but proprietary OSes (OSX, Windows, although the latter at least has the Edge images that work everywhere). Ultimately I fee…

Just a note - you can host your own CI node (runner) for project(s) on gitlab.com. It's super simple to setup, too. https://docs.gitlab.com/runner/install/linux-repository.html

This doesn't solve issues in runner-to-base comms. I had tried this kind of setup relatively recently, and almost every 10-15th build had failed for me because GitLab wasn't healthy (502 from Docker registry or problems up/downloading artifacts between stages, etc.)

Fully self-hosted looks like the only sane way. Harder to set up, but at least one can check the whole chain that way.

Re: Blue Ocean

#105
post #39

Hey there, I am the community leader for Jenkins Blue Ocean and Product Manager for the project at CloudBees. It's really great to see Jenkins users getting excited about Blue Ocean! Please let us know if there are any missing features that are blocking your team from adopting Blue Ocean. We know there are some gaps between Jenkins Classic and Blue Ocean and while we have some good ideas, we are relying on your feedb…

Hi, will BlueOcean have proper restartable stages in the pipeline? Or will it be Jenkins 2.0 pipeline under the hood? Thanks!

Re: Blue Ocean

#106
post #44
post #16

Seeing how much people recommend other solutions, I've actually moved from Travis to Jenkins, and never looked back. Yes, Jenkins has its issues (crappy UX, poor/awkward docs), but where it shines is the fact it's self-hosted, so I can SSH onto the instance to debug a failing build or replay it with a modified Jenkinsfile on the fly. I'm quite proud of the current setup we have; We're hosting our app with Google's Co…

Are you running test code in production environment? Not sure about this one

I wasn't at first either, but benefits outweigh the risks (which are all security related).

It's something I'm willing to re-think if it turns out to be problematic on any level. But so far after half a year in production, we've seen no problems.

Re: Blue Ocean

#107

They should rethink the deployment model instead. You cannot provision jenkins unattended without 3rd party hacks and undocumented features. Until this is fixed I recommend avoiding it, as you'll get pet servers. This is totally retrograde to the devops mindset. Now why should I not use that mindset if that proves to be productive at other parts of work?

>You cannot provision jenkins unattended

What do you mean by this ? what needs attending?

Re: Blue Ocean

#108
post #98

They should rethink the deployment model instead. You cannot provision jenkins unattended without 3rd party hacks and undocumented features. Until this is fixed I recommend avoiding it, as you'll get pet servers. This is totally retrograde to the devops mindset. Now why should I not use that mindset if that proves to be productive at other parts of work?

You can "apt-get install jenkins" and go straight to the webui. Or are you talking about restoring a configuration as well?

[deleted]

Re: Blue Ocean

#109
post #55

Earlier quoted context omitted.

We currently have a Jenkins setup and recently looked into both Concourse CI and GoCD as candidates for a change. We decided not go with Concourse, because it has a complex setup with bosh. Not much other use cases are really covered in the docs other than a simple one machine setup so you are left to figure things out on your own (don't really have the time to go into all that, jenkins + ec2 plugin is very simple an…

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. Nobody outside the Cloud Foundry bubble (which includes Pivotal) has any interest in using BOSH at all, and honestly, quite rightly so. It's cool there's a BOSH option for fans, but the primary deployment option has to be something accessible by the general public.

Re: Blue Ocean

#110
post #55

Earlier quoted context omitted.

We currently have a Jenkins setup and recently looked into both Concourse CI and GoCD as candidates for a change. We decided not go with Concourse, because it has a complex setup with bosh. Not much other use cases are really covered in the docs other than a simple one machine setup so you are left to figure things out on your own (don't really have the time to go into all that, jenkins + ec2 plugin is very simple an…

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…

[deleted]
Post reply on HN