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

71–80 of 185 posts

Re: Blue Ocean

#71

Post by i386 »

Xantier wrote: post #69
i386 wrote: 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.

Thanks for the feedback. Good news! This is really close to shipping. Here's a sneak peek of what it will look like when it does https://issues.jenkins-ci.org/secure/attachment/34625/Input+...

You can watch the ticket on our JIRA to get notifications for when it is completed https://issues.jenkins-ci.org/browse/JENKINS-38494

Re: Blue Ocean

#72

Post by jacques_chester »

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

I think one thing GitlabCI lost in taking inspiration from Concourse (amongst other tools!) was the centrality of resources. It wasn't obvious at first why this is so important, I and most others fixated on the other visible differences (containers for everything, declarative config, pipeline view etc).

There are a lot of features that don't need to be added to the core because they can be resources instead.

For git-triggered builds, I use the git resource. Periodic, I use the time resource or a cron resource. S3 triggered, I use the S3 resource. Triggered on release of new software to PivNet, I use pivnet-resource. Triggered on a new docker image, I use docker image resource. And so on.

Any resource that has a 'get' operation can trigger a build. 3rd parties can add triggers without needing to avoid interference with other resources, because every operation is isolated.

Disclosure: I work for Pivotal, which sponsors Concourse.

Re: Blue Ocean

#73

Post by Dowwie »

i386 wrote: 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…

Why isn't this the next Jenkins rather than a fork?

Re: Blue Ocean

#74

Post by i386 »

msane wrote: post #26

This looks great. After this the next step for Jenkins should be to change the name.

Glad you think so! Not sure about the name change though - we're pretty attached to it!

Re: Blue Ocean

#75

Post by yawgmoth »

i386 wrote: post #58
Terretta wrote: post #40

Earlier quoted context omitted.

I'd be very interested in i386's comments here.

TBH there's not much I can say on this as its not my particular area of focus (I'm the "bring CD to everyone" kinda guy) but I and other community members do recognise it is a problem that we want to solve. With Pipeline there is a trend to moving job configuration to source control and I think that direction will make things more Ops friendly as time goes by.

I wouldn't call it just a trend, it's part and parcel with the DevOps philosophy. Infrastructure as code, in source control. It's more of a conclusion, the trend is adoption.

Re: Blue Ocean

#76

Post by supergreg »

sytse wrote: post #63
supergreg wrote: post #53

Earlier quoted context omitted.

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?

Only 5 users. We are using Gitlab from Bitnami which I'm sure is using the Omnibus package. Maybe they configure it differently. I'll check, thanks.

Re: Blue Ocean

#77

Post by donatj »

tzaman wrote: 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…

We run Drone and are very happy with it. Really easy to install and get working, similar but better usage than Travis, open source, Docker powered. I really hope it catches on more strongly because it's fantastic.

Re: Blue Ocean

#78

Post by petetnt »

i386 wrote: post #42
petetnt wrote: post #11

I have been using Blue Ocean as the radiator view for our Jenkins projects for a long while now and it does look really nice and sleek. That said, currently that's pretty much the extend it can be used for. I'd say it has about ~5% feature parity with the "old" UI currently, which means that there's not much to do than just look at the pretty progress bars. Can't wait for this to progress though, the old UI of Jenkin…

Thanks for the complement. It's hard building a new UX for a tool like Jenkins. It can be difficult to pick the next thing to work on because one feature could be the killer feature for one developer but not the other. Is there anything in particular that blocks you from using it day to day?

Thanks for replying! (First, our Blue Ocean plugin is at 12b currently, so some of these might be already there).

I agree with the difficulty with picking the next UX piece to build and as such I guess most of my "wants" are mostly for me. I spend most of the time in Jenkins fiddling around in the settings, plugins and credentials and such I'd love to see "/credentials", "/configure", "/configureSecurity", "/pluginManager" and maybe "/log" and "/load-statistics" under the Administration tab.

These would alone lower the need for the old UX for myself close to nil, as the pipelines are mostly automatically managed by our (Jenkinsfile based) integrations. I do see how the administration part will be really painful, as all the conventions used by plugins would be have to be "ported" somehow first I assume?

Re: Blue Ocean

#80

Post by i386 »

Dowwie wrote: post #73
i386 wrote: 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…

Why isn't this the next Jenkins rather than a fork?

It's not a fork. It's the next generation interface for Jenkins and you can install it as a plugin side-by-side with the classic Jenkins.
Post reply on HN