18 ms·

Blue Ocean

509 points by bauerpl 10y ago

djsumdog 10y ago
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 forward and developing plugins/tools like this.
- nubela 10y ago
  Why Gitlab CI? What makes it better than Jenkins?
  - petepete 10y ago
    I think the consensus is that Jenkins offers more power and flexibility at the cost being more complicated to set up. GitLab CI is easier to get up and running with and superbly integrated with GitLab (as one would hope).
    - sytse 10y ago
      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 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 following CI improvements (not all will be ready, some will slip to Jan 22): Pipelines for Merge Requests https://gitlab.com/gitlab-org/gitlab-ce/issues/23902 https://gitlab.com/gitlab-org/gitlab-ce/issues/23902 Remove Builds tab from Merge Requests and Commits https://gitlab.com/gitlab-org/gitlab-ce/issues/23638 https://gitlab.com/gitlab-org/gitlab-ce/issues/23638 Make pipeline graph nodes bigger and responsive https://gitlab.com/gitlab-org/gitlab-ce/issues/22088 https://gitlab.com/gitlab-org/gitlab-ce/issues/22088 Direct link from pipeline list to builds https://gitlab.com/gitlab-org/gitlab-ce/issues/19703 https://gitlab.com/gitlab-org/gitlab-ce/issues/19703 Part of the issues in Improve reliability of CI/CD https://gitlab.com/gitlab-org/gitlab-ce/issues/24361 https://gitlab.com/gitlab-org/gitlab-ce/issues/24361
      - supergreg 10y ago
        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.
        sytse 10y ago
        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?
        supergreg 10y ago
        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.
        sytse 10y ago
        The Bitnami package indeed doesn't include any of this. I strongly recommend switching to Omnibus. From https://about.gitlab.com/installation/ https://about.gitlab.com/installation/ "One-click installers are frequently out of date and might not contain our Omnibus packages. An example of this are the Bitnami packages in the past couldn't be updated and are now much harder to update than the Omnibus packages. We advise to not use one-click installers but instead start an vanilla Ubuntu instance and use the recommended Omnibus package installation. This is almost as quick as a one-click install and you're sure of the latest version and easy upgrades."
    - mi100hael 10y ago
      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.
      - sytse 10y ago
        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 when working on the public internet.
        mi100hael 10y ago
        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.
        sytse 10y ago
        I agree it is a tradeoff. It is very hard to make both local and remote easy. We opted to make the right thing the easy thing to do. That means it is harder to set up than Jenkins that default to local builds. But we hope the experience of https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/docs/commands/README.md#interactive-registration https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/ma... is a lot easier than setting up build slaves in Jenkins https://wiki.jenkins-ci.org/display/JENKINS/Distributed+builds https://wiki.jenkins-ci.org/display/JENKINS/Distributed+buil...
- i386 10y ago
  Thanks for the praise and enthusiasm - comments like this make all the hard work worthwhile :)
tobiaswk 10y ago
Can't wait to try this out. It looks very good. It also looks very simplified which I like.
sidcool 10y ago
The new release of GoCD, 16.12, is also filled with amazing UI improvements. It's great to see Jenkins making Pipelines as first class citizens.
- jacques_chester 10y ago
  I'm a Concourse nut, which was partly inspired by GoCD. I'm not sure Jenkins is really making pipelines first class in the same way GoCD or Concourse do. In particular, there will be a painful period where some plugins work well and some don't, because plugins are difficult to cleanly compose. Disclosure: I work for Pivotal, which sponsors Concourse development.
  - sidcool 10y ago
    I tried the new Jenkins update, it's quite buggy at the moment. I am going to stick to GoCD for now.
kuboris 10y ago
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 jenkins. PS: For now its just a presentation tool for management :)
- deng 10y ago
  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 because of some internal API changes which are not yet properly handled by some plugin.
  - jacques_chester 10y ago
    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.
    - dserodio 10y ago
      I'd love to see -- or even better, read :) -- about how you "compose on resources".
ergo14 10y ago
I like blue ocean - but wouldn't moving to something like Concourse CI or GOCD be a better idea in the end?
- atbentley 10y ago
  Possibly, however large enterprises might lock CI/CD down and manage it centrally. In those cases they're likely running Jenkins and Blue Ocean looks a breath of fresh air for the folk in those sorts of situations.
- guitarbill 10y ago
  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.
  - solarengineer 10y ago
    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.
- gldalmaso 10y ago
  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 and just works). Also the minimal GUI, very CLI-centric. this is more of a particular thing, since I don't think that our current team will be comfortable with that UX and we have to weight this in. We did like the docker-centric approach and specially the postgres backend that makes for a much more flexible maintenance story. We decided not to go with GoCD simply because it feels very similar to jenkins in several aspects, but all concepts and workflow are different so we would have to relearn all that we do in jenkins in the GoCD way. Also redo all ops involved in backup, update etc. I just didn't find the killer feature to justify going through it. The postgres backend would maybe have caught my attention if it wasn't offered as an add-on for the expensive paid version. In the end just decided to leverage more of Jenkins 2.x pipelines with shared libs instead of having independently configured jobs that are bothersome to maintain. Will probably make some changes to our agents to leverage more of docker instead of messing with AMIs. Another major factor is the size of community, which alleviates a lot of worries. As for Blue Ocean, I hope it evolves in the right direction, but right now it simply does not solve any problems for us. As said somewhere else, you can't build a pipeline with parameters. This is really a show stopper, parameterized builds are central to a lot jenkins use cases. Another problem is a single view for all jobs but no filter? The favorite jobs feature does not substitute either search or the view and folder way.
neoyogi9 10y ago
This looks very much similar to HP CDA (Continuous Delivery Automation), the project was later scrapped. Wish they had open sourced it.
petetnt 10y ago
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 Jenkins is archaic at best.
- i386 10y ago
  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?
  - petetnt 10y ago
    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?
    - i386 10y ago
      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/ https://jenkins.io/blog/2016/12/19/declarative-pipeline-beta...
stevehiehn 10y ago
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?
- iso-8859-1 10y ago
  No, but you can launch docker from your build script.
  - stevehiehn 10y ago
    Good to know, thanks
- i386 10y ago
  It's easy to run the whole Pipeline or just a single stage in a Docker container and even more easy with the new Declarative Pipeline that just went into beta this week https://jenkins.io/blog/2016/12/19/declarative-pipeline-beta/ https://jenkins.io/blog/2016/12/19/declarative-pipeline-beta...
- jacques_chester 10y ago
  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.
  - stevehiehn 10y ago
    I also work for Pivotal T.O & used Concourse on a recent project. Thats why this thread caught my attention :)
tzaman 10y ago
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 Container Engine (Kubernetes), so what we're doing is on every build Jenkins creates a slave agent within the same cluster (just different node pool) as the production, so the environment in which test containers are ran is identical to production, and what's more it actually talks to the same Kubernetes master, which means I can, for example, test our Nginx Reverse proxy with real backend endpoints and real certificates (that are mounted through glusterfs).
- knocte 10y ago
  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 and everybody is using it now), like travis. - Open source so that you can host it yourself in the future if you need to, like Jenkins. - Easy to use and configure, like Travis. - Free service for private repos in GitLab.com (neither Travis nor any Jenkins-service provider offer this, AFAIK). I plan to never look back.
  - tzaman 10y ago
    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!
    - sytse 10y ago
      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.html 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-registry/ https://about.gitlab.com/2016/05/23/gitlab-container-registr...
TeeWEE 10y ago
We used Jenkinsfiles and pipelines recently. And also introduce Blue Ocean on our jenkins server. It come with a few glitches: Some plugins are not compatible with Blue Ocean, causing a white-page-of-death. However I found there where already issues created for them, i just turned off the plugin. But the biggest downer, is that blue ocean is just a small UI on viewing pipelines. Its not a replacement for jenkins. And you still need the normal jenkins UI. Which doesn't handle pipelines well. I think its still very much a beta project.
- i386 10y ago
  The blank screen issue is extremely important to us to fix and we hope to have a change that fixes it shortly. It's a consequence of the new REST API depending on all the plugins installed on your system and exposing its data for JS plugins. If one plugin misbehaves then it 500s the REST response. We've got an approach to isolating per plugin failures so that you can load the page even if one plugin fails. You can follow progress here https://issues.jenkins-ci.org/browse/JENKINS-39647 https://issues.jenkins-ci.org/browse/JENKINS-39647
msane 10y ago
This looks great. After this the next step for Jenkins should be to change the name.
- i386 10y ago
  Glad you think so! Not sure about the name change though - we're pretty attached to it!
  - msane 10y ago
    I honestly think it holds the project back.
    - sumedh 10y ago
      Why do you think that? The end users of Jenkins are techies who dont really care about the name if the product does the job.
- dserodio 10y ago
  It kind of did already. It used to live at https://jenkins-ci.org https://jenkins-ci.org, and was moved to http://jenkins.io http://jenkins.io to communicate that it's not "only CI", but also CD.
  - mns06 10y ago
    It was also renamed once, from Hudson. https://en.wikipedia.org/wiki/Hudson_(software)#Hudson.E2.80.93Jenkins_split https://en.wikipedia.org/wiki/Hudson_(software)#Hudson.E2.80...
meddlepal 10y ago
I've given up on Jenkins and switched to Travis. The overhead of managing a good Jenkins setup for a small team is not worth the effort.
anjc 10y ago
You'd have to imagine that the term Blue Ocean would be trademarked for contexts like this
- phaed 10y ago
  Given the competition in the space, would it not be more aptly named Red Ocean?
kodfodrasz 10y ago
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?
- oblio 10y ago
  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.
  - kodfodrasz 10y ago
    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)
    - ek750 10y ago
      Not in docker, but I've setup a Jenkins cluster up using chef. I agree it should be easier, but it is possible today.
- Terretta 10y ago
  I'd be very interested in i386's comments here.
i386 10y ago
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 feedback to help us prioritise what to work on next. If you've got any questions feel free to drop a comment here and Ill do my best to answer them or join our Gitter community [1] Thanks, James [1] https://gitter.im/jenkinsci/blueocean-plugin https://gitter.im/jenkinsci/blueocean-plugin
- gldalmaso 10y ago
  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
  - i386 10y ago
    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 https://issues.jenkins-ci.org/browse/JENKINS-38982 - User can run parametrised pipeline https://issues.jenkins-ci.org/browse/JENKINS-38805 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 notification for any proposed designs (we'd love to have a discussion with you on the final solution) and when the feature ships in a beta release.
    - annnnd 10y ago
      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/ https://datatables.net/
hunvreus 10y ago
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 https://github.com/Wiredcraft/pipelines#readme
- jacques_chester 10y ago
  I'm a bit confused -- is this a UI for Jenkins, or a different system altogether?
  - hunvreus 10y ago
    It's a different Python thing. You can install it with just `pip install pipelines`.
- pm90 10y ago
  This actually looks interesting. You can maybe containerize it to increase adoption/reduce setup time. I agree with both the unfriendly and over-engineered part ;). But right now there is no other tool that provides a task runner PLUS all the plugins of Jenkins that provide so many features out of the box.
samuell 10y ago
See also thread from May this year: https://news.ycombinator.com/item?id=11790900 https://news.ycombinator.com/item?id=11790900
jklondon 10y ago
What's the most amazing thing you have done with this technology?
thrillgore 10y ago
This looks great. Not because of the aesthetics, but because it finally acknowledges that Groovy is absolutely useless for Pipeline. I want to try out this new workflow.
webo 10y ago
This look nice, is there a hosted version of BlueOcean? I've been looking into (preferably hosted) pipeline-based CD options because simple CIs like Travis and CircleCi are not really meant true CD. What does everybody recommend?
- scaryclam 10y ago
  Jenkins isn't really CD either. I'd suggest looking at GoCD or spinnaker, though you'd have to host both yourself. You can get away with using any of the CI tools to just run through pipelines (heck, you can do this with fancy bash scripts if you're a real masochist ;), so I guess you could use any of jenkins, CircleCI or Travis to run a pipeline. I guess it'll depend on how much you really don't want to manage a CD server yourself.
alexellisuk 10y ago
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/ http://blog.alexellis.io/tag/jenkins/ They are doing a great job at reinventing JenkinsCI (but remember it's still Java)
- pm90 10y ago
  What's wrong with Java?
  - oblio 10y ago
    Resource usage, especially RAM. And I say this as a longtime Jenkins admin.
    - falsedan 10y ago
      The amount of tooling we've had to do to track, understand, and limit Jenkins VM usage… https://jenkins.io/blog/2016/11/21/gc-tuning/ https://jenkins.io/blog/2016/11/21/gc-tuning/ is the state-of-the-art / why doesn't Jenkins set all this by default.
  - alexellisuk 10y ago
    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.
    - pm90 10y ago
      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.
    - oblio 10y ago
      Jenkins is both being actively developed and in a different niche than the others. Something isn't legacy just because there's something newer out there. Or everything is legacy :)
bryanrasmussen 10y ago
I think in the what is AI argument what has actually happened is that there have been two conversations about AI over the years - what AI is and what AI can do by virtue of being AI. In that conversation the assumption has been that AI would be in some ways self-aware and intelligent like 'Data in Star Trek' and by virtue of being self aware and intelligent it would be able to learn things from its users, it would be able to make aesthetic judgements about music and art, it would be able to create interesting art of its own and so forth. As it turns many of the things that AI will be able to do for us has been done by programs that are 'just math', the question is if in the future more or even all of AI's perceived benefits for humanity can be accomplished by just more and more complex 'math'. In the end perhaps the essence of what AI is will only be beneficial to AI itself.
- ryjm 10y ago
  Replace 'AI' with 'Jenkins' and this becomes some great satire.
  - bryanrasmussen 10y ago
    also if you replace my name with Mark Zuckerberg.
    - deleted 10y ago
      [deleted]
agibsonccc 10y ago
Esoteric use case from someone in AI: Jenkins is the only CI we've been able to use even as an open source project due to needing gpus. CI and things like special hardware is a "semi-common" edge case and a big reason to have something self hosted. Referencing other comments here: We've also found periodic builds and arbitrary jobs to be a must as well. A lot of providers out there support most of the basic stuff out of the box, and I understand why they won't go after an edge case like that. It's great to see improvements in the UX on the horizon, that has been our biggest pain point. If anyone's curious, our CI setup involves a multi OS cluster: Mac,windows,linux for power,linux x86 (with cross building for android) with 1 linux master running a gpu for gpu tests.
- thinkmassive 10y ago
  I'm in a similar situation with needing to build ARM images on native hardware. Jenkins is great!
- sytse 10y ago
  In GitLab CI you can use any machine for a build as long a you can install GitLab Runner on it. We kept the design of that simple with few dependencies and it is written in Go.
  - agibsonccc 10y ago
    We just don't use gitlab heavily enough yet :). We are mainly a JVM shop so the bias jenkins has for things like maven and what not out of the box is pretty appealing. I've been watching your integration play :). Maybe 1 day.
    - sytse 10y ago
      Thanks! I agree that great Maven support is key. We're working to integrate a package repository in https://gitlab.com/gitlab-org/gitlab-ce/issues/19095 https://gitlab.com/gitlab-org/gitlab-ce/issues/19095
  - neuland 10y ago
was_boring 10y ago
This is nice! I've been looking for a way to schedule deployments of multiple code bases at the same time, with automatic rollback support. Does this support that?
debacle 10y ago
I love to hate Jenkins. Such a nice (and remarkably simple, for what it accomplishes) piece of software. I've tried to replace it so many times, and so many times come to realize what an asset it is.

509 points by bauerpl 10y ago

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 forward and developing plugins/tools like this.

nubela 10y ago
Why Gitlab CI? What makes it better than Jenkins?
- petepete 10y ago
  I think the consensus is that Jenkins offers more power and flexibility at the cost being more complicated to set up. GitLab CI is easier to get up and running with and superbly integrated with GitLab (as one would hope).
  - sytse 10y ago
    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 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 following CI improvements (not all will be ready, some will slip to Jan 22): Pipelines for Merge Requests https://gitlab.com/gitlab-org/gitlab-ce/issues/23902 https://gitlab.com/gitlab-org/gitlab-ce/issues/23902 Remove Builds tab from Merge Requests and Commits https://gitlab.com/gitlab-org/gitlab-ce/issues/23638 https://gitlab.com/gitlab-org/gitlab-ce/issues/23638 Make pipeline graph nodes bigger and responsive https://gitlab.com/gitlab-org/gitlab-ce/issues/22088 https://gitlab.com/gitlab-org/gitlab-ce/issues/22088 Direct link from pipeline list to builds https://gitlab.com/gitlab-org/gitlab-ce/issues/19703 https://gitlab.com/gitlab-org/gitlab-ce/issues/19703 Part of the issues in Improve reliability of CI/CD https://gitlab.com/gitlab-org/gitlab-ce/issues/24361 https://gitlab.com/gitlab-org/gitlab-ce/issues/24361
    - supergreg 10y ago
      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.
      - sytse 10y ago
        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?
        supergreg 10y ago
        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.
        sytse 10y ago
        The Bitnami package indeed doesn't include any of this. I strongly recommend switching to Omnibus. From https://about.gitlab.com/installation/ https://about.gitlab.com/installation/ "One-click installers are frequently out of date and might not contain our Omnibus packages. An example of this are the Bitnami packages in the past couldn't be updated and are now much harder to update than the Omnibus packages. We advise to not use one-click installers but instead start an vanilla Ubuntu instance and use the recommended Omnibus package installation. This is almost as quick as a one-click install and you're sure of the latest version and easy upgrades."
  - mi100hael 10y ago
    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.
    - sytse 10y ago
      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 when working on the public internet.
      - mi100hael 10y ago
        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.
        sytse 10y ago
        I agree it is a tradeoff. It is very hard to make both local and remote easy. We opted to make the right thing the easy thing to do. That means it is harder to set up than Jenkins that default to local builds. But we hope the experience of https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/docs/commands/README.md#interactive-registration https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/ma... is a lot easier than setting up build slaves in Jenkins https://wiki.jenkins-ci.org/display/JENKINS/Distributed+builds https://wiki.jenkins-ci.org/display/JENKINS/Distributed+buil...
i386 10y ago
Thanks for the praise and enthusiasm - comments like this make all the hard work worthwhile :)

tobiaswk 10y ago

Can't wait to try this out. It looks very good. It also looks very simplified which I like.

sidcool 10y ago

The new release of GoCD, 16.12, is also filled with amazing UI improvements. It's great to see Jenkins making Pipelines as first class citizens.

jacques_chester 10y ago
I'm a Concourse nut, which was partly inspired by GoCD. I'm not sure Jenkins is really making pipelines first class in the same way GoCD or Concourse do. In particular, there will be a painful period where some plugins work well and some don't, because plugins are difficult to cleanly compose. Disclosure: I work for Pivotal, which sponsors Concourse development.
- sidcool 10y ago
  I tried the new Jenkins update, it's quite buggy at the moment. I am going to stick to GoCD for now.

kuboris 10y ago

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 jenkins. PS: For now its just a presentation tool for management :)

deng 10y ago
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 because of some internal API changes which are not yet properly handled by some plugin.
- jacques_chester 10y ago
  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.
  - dserodio 10y ago
    I'd love to see -- or even better, read :) -- about how you "compose on resources".

ergo14 10y ago

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

atbentley 10y ago
Possibly, however large enterprises might lock CI/CD down and manage it centrally. In those cases they're likely running Jenkins and Blue Ocean looks a breath of fresh air for the folk in those sorts of situations.
guitarbill 10y ago
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.
- solarengineer 10y ago
  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.
gldalmaso 10y ago
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 and just works). Also the minimal GUI, very CLI-centric. this is more of a particular thing, since I don't think that our current team will be comfortable with that UX and we have to weight this in. We did like the docker-centric approach and specially the postgres backend that makes for a much more flexible maintenance story. We decided not to go with GoCD simply because it feels very similar to jenkins in several aspects, but all concepts and workflow are different so we would have to relearn all that we do in jenkins in the GoCD way. Also redo all ops involved in backup, update etc. I just didn't find the killer feature to justify going through it. The postgres backend would maybe have caught my attention if it wasn't offered as an add-on for the expensive paid version. In the end just decided to leverage more of Jenkins 2.x pipelines with shared libs instead of having independently configured jobs that are bothersome to maintain. Will probably make some changes to our agents to leverage more of docker instead of messing with AMIs. Another major factor is the size of community, which alleviates a lot of worries. As for Blue Ocean, I hope it evolves in the right direction, but right now it simply does not solve any problems for us. As said somewhere else, you can't build a pipeline with parameters. This is really a show stopper, parameterized builds are central to a lot jenkins use cases. Another problem is a single view for all jobs but no filter? The favorite jobs feature does not substitute either search or the view and folder way.

neoyogi9 10y ago

This looks very much similar to HP CDA (Continuous Delivery Automation), the project was later scrapped. Wish they had open sourced it.

petetnt 10y ago

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 Jenkins is archaic at best.

i386 10y ago
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?
- petetnt 10y ago
  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?
  - i386 10y ago
    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/ https://jenkins.io/blog/2016/12/19/declarative-pipeline-beta...

stevehiehn 10y ago

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?

iso-8859-1 10y ago
No, but you can launch docker from your build script.
- stevehiehn 10y ago
  Good to know, thanks
i386 10y ago
It's easy to run the whole Pipeline or just a single stage in a Docker container and even more easy with the new Declarative Pipeline that just went into beta this week https://jenkins.io/blog/2016/12/19/declarative-pipeline-beta/ https://jenkins.io/blog/2016/12/19/declarative-pipeline-beta...
jacques_chester 10y ago
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.
- stevehiehn 10y ago
  I also work for Pivotal T.O & used Concourse on a recent project. Thats why this thread caught my attention :)

tzaman 10y ago

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 Container Engine (Kubernetes), so what we're doing is on every build Jenkins creates a slave agent within the same cluster (just different node pool) as the production, so the environment in which test containers are ran is identical to production, and what's more it actually talks to the same Kubernetes master, which means I can, for example, test our Nginx Reverse proxy with real backend endpoints and real certificates (that are mounted through glusterfs).

knocte 10y ago
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 and everybody is using it now), like travis. - Open source so that you can host it yourself in the future if you need to, like Jenkins. - Easy to use and configure, like Travis. - Free service for private repos in GitLab.com (neither Travis nor any Jenkins-service provider offer this, AFAIK). I plan to never look back.
- tzaman 10y ago
  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!
  - sytse 10y ago
    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.html 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-registry/ https://about.gitlab.com/2016/05/23/gitlab-container-registr...

TeeWEE 10y ago

We used Jenkinsfiles and pipelines recently. And also introduce Blue Ocean on our jenkins server. It come with a few glitches: Some plugins are not compatible with Blue Ocean, causing a white-page-of-death. However I found there where already issues created for them, i just turned off the plugin. But the biggest downer, is that blue ocean is just a small UI on viewing pipelines. Its not a replacement for jenkins. And you still need the normal jenkins UI. Which doesn't handle pipelines well. I think its still very much a beta project.

i386 10y ago
The blank screen issue is extremely important to us to fix and we hope to have a change that fixes it shortly. It's a consequence of the new REST API depending on all the plugins installed on your system and exposing its data for JS plugins. If one plugin misbehaves then it 500s the REST response. We've got an approach to isolating per plugin failures so that you can load the page even if one plugin fails. You can follow progress here https://issues.jenkins-ci.org/browse/JENKINS-39647 https://issues.jenkins-ci.org/browse/JENKINS-39647

msane 10y ago

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

i386 10y ago
Glad you think so! Not sure about the name change though - we're pretty attached to it!
- msane 10y ago
  I honestly think it holds the project back.
  - sumedh 10y ago
    Why do you think that? The end users of Jenkins are techies who dont really care about the name if the product does the job.
dserodio 10y ago
It kind of did already. It used to live at https://jenkins-ci.org https://jenkins-ci.org, and was moved to http://jenkins.io http://jenkins.io to communicate that it's not "only CI", but also CD.
- mns06 10y ago
  It was also renamed once, from Hudson. https://en.wikipedia.org/wiki/Hudson_(software)#Hudson.E2.80.93Jenkins_split https://en.wikipedia.org/wiki/Hudson_(software)#Hudson.E2.80...

meddlepal 10y ago

I've given up on Jenkins and switched to Travis. The overhead of managing a good Jenkins setup for a small team is not worth the effort.

anjc 10y ago

You'd have to imagine that the term Blue Ocean would be trademarked for contexts like this

phaed 10y ago
Given the competition in the space, would it not be more aptly named Red Ocean?

kodfodrasz 10y ago

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?

oblio 10y ago
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.
- kodfodrasz 10y ago
  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)
  - ek750 10y ago
    Not in docker, but I've setup a Jenkins cluster up using chef. I agree it should be easier, but it is possible today.
Terretta 10y ago
I'd be very interested in i386's comments here.

i386 10y ago

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 feedback to help us prioritise what to work on next. If you've got any questions feel free to drop a comment here and Ill do my best to answer them or join our Gitter community [1] Thanks, James [1] https://gitter.im/jenkinsci/blueocean-plugin https://gitter.im/jenkinsci/blueocean-plugin

gldalmaso 10y ago
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
- i386 10y ago
  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 https://issues.jenkins-ci.org/browse/JENKINS-38982 - User can run parametrised pipeline https://issues.jenkins-ci.org/browse/JENKINS-38805 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 notification for any proposed designs (we'd love to have a discussion with you on the final solution) and when the feature ships in a beta release.
  - annnnd 10y ago
    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/ https://datatables.net/

hunvreus 10y ago

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 https://github.com/Wiredcraft/pipelines#readme

jacques_chester 10y ago
I'm a bit confused -- is this a UI for Jenkins, or a different system altogether?
- hunvreus 10y ago
  It's a different Python thing. You can install it with just `pip install pipelines`.
pm90 10y ago
This actually looks interesting. You can maybe containerize it to increase adoption/reduce setup time. I agree with both the unfriendly and over-engineered part ;). But right now there is no other tool that provides a task runner PLUS all the plugins of Jenkins that provide so many features out of the box.

samuell 10y ago

See also thread from May this year: https://news.ycombinator.com/item?id=11790900 https://news.ycombinator.com/item?id=11790900

jklondon 10y ago

What's the most amazing thing you have done with this technology?

thrillgore 10y ago

This looks great. Not because of the aesthetics, but because it finally acknowledges that Groovy is absolutely useless for Pipeline. I want to try out this new workflow.

webo 10y ago

This look nice, is there a hosted version of BlueOcean? I've been looking into (preferably hosted) pipeline-based CD options because simple CIs like Travis and CircleCi are not really meant true CD. What does everybody recommend?

scaryclam 10y ago
Jenkins isn't really CD either. I'd suggest looking at GoCD or spinnaker, though you'd have to host both yourself. You can get away with using any of the CI tools to just run through pipelines (heck, you can do this with fancy bash scripts if you're a real masochist ;), so I guess you could use any of jenkins, CircleCI or Travis to run a pipeline. I guess it'll depend on how much you really don't want to manage a CD server yourself.

alexellisuk 10y ago

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/ http://blog.alexellis.io/tag/jenkins/ They are doing a great job at reinventing JenkinsCI (but remember it's still Java)

pm90 10y ago
What's wrong with Java?
- oblio 10y ago
  Resource usage, especially RAM. And I say this as a longtime Jenkins admin.
  - falsedan 10y ago
    The amount of tooling we've had to do to track, understand, and limit Jenkins VM usage… https://jenkins.io/blog/2016/11/21/gc-tuning/ https://jenkins.io/blog/2016/11/21/gc-tuning/ is the state-of-the-art / why doesn't Jenkins set all this by default.
- alexellisuk 10y ago
  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.
  - pm90 10y ago
    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.
  - oblio 10y ago
    Jenkins is both being actively developed and in a different niche than the others. Something isn't legacy just because there's something newer out there. Or everything is legacy :)

bryanrasmussen 10y ago

I think in the what is AI argument what has actually happened is that there have been two conversations about AI over the years - what AI is and what AI can do by virtue of being AI. In that conversation the assumption has been that AI would be in some ways self-aware and intelligent like 'Data in Star Trek' and by virtue of being self aware and intelligent it would be able to learn things from its users, it would be able to make aesthetic judgements about music and art, it would be able to create interesting art of its own and so forth. As it turns many of the things that AI will be able to do for us has been done by programs that are 'just math', the question is if in the future more or even all of AI's perceived benefits for humanity can be accomplished by just more and more complex 'math'. In the end perhaps the essence of what AI is will only be beneficial to AI itself.

ryjm 10y ago
Replace 'AI' with 'Jenkins' and this becomes some great satire.
- bryanrasmussen 10y ago
  also if you replace my name with Mark Zuckerberg.
  - deleted 10y ago
    [deleted]

agibsonccc 10y ago

Esoteric use case from someone in AI: Jenkins is the only CI we've been able to use even as an open source project due to needing gpus. CI and things like special hardware is a "semi-common" edge case and a big reason to have something self hosted. Referencing other comments here: We've also found periodic builds and arbitrary jobs to be a must as well. A lot of providers out there support most of the basic stuff out of the box, and I understand why they won't go after an edge case like that. It's great to see improvements in the UX on the horizon, that has been our biggest pain point. If anyone's curious, our CI setup involves a multi OS cluster: Mac,windows,linux for power,linux x86 (with cross building for android) with 1 linux master running a gpu for gpu tests.

thinkmassive 10y ago
I'm in a similar situation with needing to build ARM images on native hardware. Jenkins is great!
sytse 10y ago
In GitLab CI you can use any machine for a build as long a you can install GitLab Runner on it. We kept the design of that simple with few dependencies and it is written in Go.
- agibsonccc 10y ago
  We just don't use gitlab heavily enough yet :). We are mainly a JVM shop so the bias jenkins has for things like maven and what not out of the box is pretty appealing. I've been watching your integration play :). Maybe 1 day.
  - sytse 10y ago
    Thanks! I agree that great Maven support is key. We're working to integrate a package repository in https://gitlab.com/gitlab-org/gitlab-ce/issues/19095 https://gitlab.com/gitlab-org/gitlab-ce/issues/19095
- neuland 10y ago

was_boring 10y ago

This is nice! I've been looking for a way to schedule deployments of multiple code bases at the same time, with automatic rollback support. Does this support that?

debacle 10y ago

I love to hate Jenkins. Such a nice (and remarkably simple, for what it accomplishes) piece of software. I've tried to replace it so many times, and so many times come to realize what an asset it is.