Live data from Hacker News

Blue Ocean

jenkins.io

61–70 of 185 posts

Re: Blue Ocean

#61
post #6

I like blue ocean - but wouldn't moving to something like Concourse CI or GOCD be a better idea in the end?

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…

Whoa... GoCD is a major superset of what Jenkins (or anyone else) provides! Pipelines are first-class constructs - beyond the visual representation and the Value Stream Map. There is full end-to-end audit-ability and traceability, you don't have to resort to any hacks to mix 'n match components.

Do contact the community on the GoCD mailing list to understand what it takes to migrate from Jenkins to GoCD.

Meanwhile, please also check https://build.go.cd/ (user -> view, password -> password) to understand some of what's possible.

Re: Blue Ocean

#62

We've actually built Pipelines [1] for that very reason; Jenkins has always felt over-engineered and unfriendly. I'd be very interested in hearing from folks who are familiar with it what they think of our alternative. [1]: https://github.com/Wiredcraft/pipelines#readme

I'm a bit confused -- is this a UI for Jenkins, or a different system altogether?

Re: Blue Ocean

#63
post #15

Earlier quoted context omitted.

We also want to offer all the power and flexibility of Jenkins but we still have some work ahead of us. The idea is to add those features to GitLab itself and not to plugins. Plugins tend to cause brittleness https://news.ycombinator.com/item?id=13218391 We want to make sure that you can upgrade GitLab without having to worry about things breaking. For the current GitLab release (8.15, December 22) we planned the fol…

Does these pipelines thing imply moving away from Sidekiq? At work that's our biggest issue with Gitlab. Sidekiq dies all the time and Gitlab has to be restarted for merge requests to work again.

These pipelines do not imply moving away from Sidekiq. Have you tried using the Omnibus package? It contains logic to make sure restarting Sidekiq is automatic. How much memory does GitLab have and how many users?

Re: Blue Ocean

#64
post #6

I like blue ocean - but wouldn't moving to something like Concourse CI or GOCD be a better idea in the end?

Really depends. When I tried it, GoCD sucked a bit for shell-script/makefile based build processes, but worked really well for Java/C#. Also IMO, Jenkins has a less-steep learning curve and is far easier to set up and for devs to modify themselves. But everybody loves shiny things.

I'm building my entire operating system using GoCD. Once you start to mature in your development practices, you start to realise the need for first class pipelines and more.

Re: Blue Ocean

#65

We've actually built Pipelines [1] for that very reason; Jenkins has always felt over-engineered and unfriendly. I'd be very interested in hearing from folks who are familiar with it what they think of our alternative. [1]: https://github.com/Wiredcraft/pipelines#readme

I'm a bit confused -- is this a UI for Jenkins, or a different system altogether?

It's a different Python thing. You can install it with just `pip install pipelines`.

Re: Blue Ocean

#66
post #2

Wow, this looks amazing. I really want to try this out. On my current contract, we've been moving away from Jenkins and towards Gitlab CI. I still work on an opensource project that uses Jenkins to build. The screenshots show a really good pipeline layout. It seems like it's similar in power to Gitlab CI, but also looks like it has way better visual representations and UI. I'm glad the Jenkins team is still moving fo…

Thanks for the praise and enthusiasm - comments like this make all the hard work worthwhile :)

Re: Blue Ocean

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

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

Re: Blue Ocean

#68
post #7
post #5

I just want to mention that I loved the idea of BlueOcean at the begining. It looks sleak an works well with pipeline. However, for us it's unusable in production setting. I know that it's still in beta, but as one example it doesn't support parameters. When user starts a job through BlueOcean it will fail.(Officialy they don't plan to implement it any time soon as I found out) That means It stays disabled in our jen…

Well, that's Jenkins in a nutshell. You usually need to extend Jenkins with lots of plugins because they provide functionality that should have been in core in the first place. Then you realize that those plugins are not properly sandboxed and often do not work well together (especially with multi-configuration builds), not to speak of how updating Jenkins becomes a nightmare with plugins breaking left and right beca…

In fairness, Jenkins did not have the benefit of hindsight. Plugins were the this-is-how-you-support-extension architectural style of the period (see also Wordpress, Eclipse).

I've been working on a Concourse tutorial video series. One of the points I've made is that plugins are unsafe to compose. They need to know too much about each other to prevent interference.

Concourse instead composes on resources, which all have an identical interface (check, get, put). You can pretty much use any resource with any other resource if they achieve your purpose.

We're still calling Concourse "CI/CD", but folk are now jokingly referring to "Continuous Everything" at Pivotal. Because it really is becoming the first tool for everything. We're running large automatic tooling with small teams, because it's easy to extend and relatively easy to rearrange.

Disclosure: I work for Pivotal, which sponsors Concourse development.

Re: Blue Ocean

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

We have blue ocean installed on our Jenkins instances and I periodically check when it is suitable for our use. Currently our promotions to environments etc. use `input` step on the pipeline. This is, for now, the main thing that blocks us from using blue ocean.

Re: Blue Ocean

#70
post #19
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…

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…

Do you really find Travis easy to use and configure?

I've used TeamCity a lot and find the functionality to be decent to good but the UI horrible. Perhaps a bit biased because I had access to the server and agents in that case. A lot of debugging/discoverability issues are easier with full access of course.

I've then used Travis a bit for small GitHub projects (and contributing to other people's projects) and it has a nice UI for simple stuff. However, it gives the impression that they are struggling to stay alive - many features are in beta or feel like they are; a lot is under-documented or planned soon (for multiple years). I know I can dig into their various projects' source code to find out how things work, but I always feel incredibly unproductive figuring something out in Travis. I worry for them. Great to hear you have a good experience with GitLab!

Post reply on HN