It's not completely clear to me from reading the site - does this run a non-dockerized app build in kubernetes, or does it also work for building and deploying my app as a docker container itself? This usually requires things like being able to spin up a cluster of containers per build - one with my app, one with a database to run against, maybe one with memcached or elasticsearch for integration tests, etc. And does it work out of the box for complicated cases like partitioning a large test suite to run in parallel, where each parallel part of the build needs its own mini cluster of a couple of containers talking to each other?
I haven't looked into the current state of this recently but I ran into a lot of problems with this with a bunch of hosted CI services in the past. Somewhat ironically, as of a couple years ago if you needed to build your own docker container as part of a build you had to specifically stay clear of CI services that mentioned docker at all because that meant they were running their builds inside of containers and it was a pain to figure out how to run my own docker build, much less spin up a cluster per build with something like docker-compose, inside of a running container.
Curious if and how Jenkins X solves this. Or have things changed and it's now easy to build and run docker containers inside of a container?
(Aside from that, I'm not sure how I feel about Jenkins coordinating with a Kubernetes cluster. I've always found their monolithic approach to be a pain to work with, and always wished that, for example, I could just have Jenkins trigger jobs by pushing them onto an ActiveMQ queue or something and read back the results on another queue. Then I could just set up an autoscaling group of build servers, and provision them with whatever tools I'm already using to just start up and listen on this queue. Instead, jenkins wants me to duplicate a lot of this work I already have CM tools doing, and set it up manually through the UI, using community plugins that are often out of date).