Live data from Hacker News

Blue Ocean

jenkins.io

81–90 of 185 posts

Re: Blue Ocean

#81
post #50

Earlier quoted context omitted.

Hi, thanks for your effort in enhancing jenkins UX. Here are some important features I believe should be looked into if not already. - since there is a single view, searching for jobs is essential. it's hard to find jobs to favorite among hundreds - run builds with parameters, I believe a lot of jenkins setups are heavily leveraging parameterized builds, pipeline included

You're most welcome! The good news is that both of those features are planned - User would like to have a fast smart search to find jobs from the dashboard https://issues.jenkins-ci.org/browse/JENKINS-38982 - User can run parametrised pipeline https://issues.jenkins-ci.org/browse/JENKINS-38805 Particularly for search, I'd recommend signing up to our JIRA and watching both of those issues. You will be able to get a no…

Nice to see someone working on Jenkins UI, looks good!

About the search: there are many JS libraries which allow pagination, sorting and searching tables, so it might be fastest (and most user-friendly) to just use one of those. Well, as long as we-re talking about 100s of jobs and not 1000s... :) For instance, I had great fun dealing with DataTables [0] lately (needs jQuery). The advantage of this approach is that it takes half an hour tops to implement.

[0] https://datatables.net/

Re: Blue Ocean

#82
post #58

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.

Not only job configuration. But the entire configuration of your jenkins setup. For example this issue was a blocking factor for automatically provisioning a new jenkins. https://issues.jenkins-ci.org/browse/JENKINS-34035

Re: Blue Ocean

#83
post #49

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?

I'm not sure I get the "provision Jenkins part". Slaves "self install" once you have a working SSH connection and the master is just a bunch of XML files.

Have you tried setting up the jenkins docker image? I'd expect an experience where it works out of the box, or works out of the box after setting up some environment variables.

Actual experience: you need to manually click a wizard, and set up an admin password, or google and find a hidden github issue of an ansible playbook with a workaround how to make jenkins startable for the first time unattended.

Just a bunch of xmls? Which ones? With what content? Have you tried ansible for example? I'd like to declaratively define my initial setup:

- jenkins admin password, users, passwords, roles, ssh keys - slaves - jenkins plugins can be listed and are installed - git repository lists which contain the Jenkinsfiles

Good luck doing this non-iteractively with those bunch of XML files... (the jenkins cli randomly does not support parts of these steps)

Re: Blue Ocean

#84

Looks awesome really. The pipeline U.I. is similar to PIVOTAL's Concourse C.I. I wonder if each job is in a separate container?

Pivotal is the sponsor of Concourse. It's an open source project in its own right. Blue Ocean is a definite improvement for Jenkins shops, for some such places it may be a more sensible alternative to switching. Disclosure: I work for Pivotal.

I also work for Pivotal T.O & used Concourse on a recent project. Thats why this thread caught my attention :)

Re: Blue Ocean

#85
post #21
post #20

Earlier quoted context omitted.

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!

GitLab CI has proper Docker support. You can set a default docker image for each runner `--docker-image ruby:2.1` or set one for the project in the .gitlab-ci.yml file. For more information see https://docs.gitlab.com/ce/ci/docker/using_docker_images.htm... Did you know GitLab also comes with a private container registry? https://about.gitlab.com/2016/05/23/gitlab-container-registr...

Also notable is services like docker-in-docker (and privileged docker containers) are allowed, which is a huge win over services like Atlassian's Pipelines.

Without dind, it's really hard/annoying to us CI/CD to build docker images. But with Gitlab, they also provide a place to store docker images (the "registry") right next to your code, for free!

At work, we're investigating moving to Gitlab for everything except issues (which we'd need to keep on JIRA for now since we're so embedded with it). It looks like Gitlab does have some integration with JIRA, but it's project-level, and it would be nice if it could be group-level since we have many small repos. :)

(I don't have an affiliation with Gitlab, I'm just super happy with the service.)

EDIT: typo

Re: Blue Ocean

#86
post #81
post #50

Earlier quoted context omitted.

You're most welcome! The good news is that both of those features are planned - User would like to have a fast smart search to find jobs from the dashboard https://issues.jenkins-ci.org/browse/JENKINS-38982 - User can run parametrised pipeline https://issues.jenkins-ci.org/browse/JENKINS-38805 Particularly for search, I'd recommend signing up to our JIRA and watching both of those issues. You will be able to get a no…

Nice to see someone working on Jenkins UI, looks good! About the search: there are many JS libraries which allow pagination, sorting and searching tables, so it might be fastest (and most user-friendly) to just use one of those. Well, as long as we-re talking about 100s of jobs and not 1000s... :) For instance, I had great fun dealing with DataTables [0] lately (needs jQuery). The advantage of this approach is that i…

We're built on React but I'll forward this on to the team to check it out. Thanks for the tip!

Re: Blue Ocean

#87
post #36
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…

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

Was looking for this comment! CircleCI is amazing. We use it and it seems to offer us everything we need in a very nice shiny box.

Re: Blue Ocean

#88
post #25
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…

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

Re: Blue Ocean

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

> or that isn't intrinsically linked to a git repo

This is required because the configuration is versioned in the git repository.

> has no concept of a build triggering arbitrarily

This is not entirely correct anymore. Drone can trigger builds and deployments using the API or the command line utility, and there is a PR to add to the user interface [1]. The caveat is you need to trigger from an existing build or commit, because Drone needs a commit sha to fetch the configuration from the repository.

There are individuals using Drone + cron to execute scheduled tasks such as security scans and nightly integration tests.

[1] https://github.com/drone/drone-ui/pull/69

Re: Blue Ocean

#90
post #78
post #42

Earlier quoted context omitted.

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", "/pluginMa…

Administration tasks are not really in our scope yet (at least not for 1.0 as it's a huge job to boil the ocean, so to speak) and our focus is on making the best developer experience for CD Pipelines.

There's a lot of job level configuration that's moving into the Jenkinsfile with Declarative Pipeline [1], such as triggers, and you can expect that process to continue.

You're right on the plugin conventions having to be entirely ported. There's a whole new UI stack that those plugins have to adopt and we have to think carefully about how we design those extension points rather than blindly pulling them into the UI.

[1] https://jenkins.io/blog/2016/12/19/declarative-pipeline-beta...

Post reply on HN