5 ms·

Nice to know there is a plan and it's refreshing to see that they can understand most of the problems from the customer perspective now. I hope they address th

Nice to know there is a plan and it's refreshing to see that they can understand most of the problems from the customer perspective now. I hope they address the constant shifts in focus with this plan and Jenkins can secure it's market spot, it really deserves it from a historical point of view in the least. It should not be a Nokia or a Xerox, it's better than that and has been a major tool for the industry. The whole CRD is a great way to move forward, but Argo is looking great right now and it's way ahead, if they manage to finish it soon and make it production ready it will be hard to beat it. The problem is that every segment has it's player now and there are some big ones, GiLab, GoCD, Spinnaker, Concourse... So many tools and the difference is that most of them have more focus than Jenkins does, they also have newer code and more speed, each has a niche but Jenkins has the market share, it will be an interesting match. Jenkins is fighting a bit of a uphill battle but with a huge army. I hope they keep it simple, focus in being the best in one or 2 things and then scale to other areas, that is my 2 cents.

twic 8y ago
First i've heard of Argo CI. Why would i want that rather than Concourse? Which can now be deployed on Kubernetes, it seems: https://github.com/helm/charts/tree/master/stable/concourse https://github.com/helm/charts/tree/master/stable/concourse
- jacques_chester 8y ago
  Concourse's components (ATC, DB, Workers) can run on Kubernetes, but it is still handling the scheduling of containers it creates. Delegating container scheduling to Kubernetes is the next major epic on the Core track for Concourse. As for Argo: I am not particularly in favour of Turing-complete YAML. Disclosure: I really like Concourse. I work for Pivotal, which sponsors Concourse development.
  - cfontes 8y ago
    Valid point. Don't fly you end up creating a turing-complete config file as well? I remember it being stored as some kind of Yaml like syntax.
    - jacques_chester 8y ago
      Fly does substitutions, but that's it: no loops, no if-thens. It's almost certain that something can be tickled into being Turing-complete; it's actually devilishly difficult to avoid doing it by accident. My hunch is pipelines are Turing complete, but I haven't gotten around to proving it. But there's a difference between trying not to introduce it and going out of your way to build a programming language in YAML. An actual, honest-to-god programmable YAML.
  - twic 8y ago
    Wait, doesn't Pivotal also sponsor Turing-complete YAML development?
    - jacques_chester 8y ago
      BOSH v1 manifests were Lovecraftian. Well beyond Turing and into the deep underdark of the Beyondness That Must Not Be Yea Even Unto Enterprise.
- cfontes 8y ago
  I am no Concourse expert, but I've tried it a couple times. Concourse's interface is just beautiful and functional, the CLI is great as well, but it has it's own ecosystem. Lot's of tools to solve problems that K8s already solves (Jobs, Volumes, resources, scheduling, etc..) it also uses workers which if I remember correctly is just like a scheduled slave which you need to install stuff into. Argo is a different beast, it uses k8s like it should be done in my view. It schedules container to one or multiple k8s Clusters, using CRDs which is kind of a DSL on top of the k8s api. It does not run slaves, is simply a debian or busybox pod, a Job or other resource that runs and returns pakages to the workflow or pass it on. The Syntax, is K8S YAML syntax, the same with a couple more things, very little learning curve if you know K8S YAMLs, Concourse is a very different thing. BTW I have zero to do with Argo, I just find it awesome and am waiting for it to be more stable.
  - jacques_chester 8y ago
    > Lot's of tools to solve problems that K8s already solves In fairness, Concourse predates Kubernetes and was invented developed to support a team working on a different container scheduler (Diego, similar vintage to Kubernetes). Otherwise you're right. The pain of carrying around its own container scheduling, worker management etc has been a notably hefty thorn in the side of Concourse for the last two years or so. It should go away as Concourse gets rebased onto Kubernetes. > The Syntax, is K8S YAML syntax, the same with a couple more things, very little learning curve if you know K8S YAMLs, Concourse is a very different thing. As part of my work in and around Knative Build, Topher Bullock and I wrote a little façade Kubernetes controller[0] that lets you send pipelines and see builds from kubectl. Basically it looks like an existing Concourse pipeline, but with the usual k8s boilerplate. I'm not sure what the final Concourse-on-Kubernetes will look like. kubectl is showing one-size-fits-all discomfort (see, for example, knctl[1]) and I am not sold that CRDs are suitable for every purpose. 2018 is clearly The Year of the CRD, so I figure we're about 18 months away from the trough of disillusionment on those. [0] https://github.com/jchesterpivotal/knative-build-pipeline-poc/commits/master https://github.com/jchesterpivotal/knative-build-pipeline-po... [1] https://github.com/cppforlife/knctl https://github.com/cppforlife/knctl
jstrachan 8y ago
Jenkins X can help compete effectively with other tools since it automates your entire CI/CD; from creating the Pipelines, setting up your Environments, creating Preview Environments on each Pull Request and then performing GitOps based promotion through your Environments on each release. I'm looking forward to seeing the Jenkins ecosystem expand to offer similar automated CI/CD for other platforms too (e.g. Terraform / Ansible / VMs etc)
- cfontes 8y ago
  I saw Jenkins X a few months ago, it indeed looks interesting, I have not used it as it's super new and I don't trust Cloudbees on the super new stuff anymore. I wish you guys all the best and I hope to use it in the future. Talking about right now, if I remember correctly Concourse+Bosh can do a lot of that as well and it's a lot more battle tested so it's not like Jenkins X is all alone there on the "we can do everything" spot but it's refreshing to see it in the fight.

twic 8y ago

First i've heard of Argo CI. Why would i want that rather than Concourse? Which can now be deployed on Kubernetes, it seems: https://github.com/helm/charts/tree/master/stable/concourse https://github.com/helm/charts/tree/master/stable/concourse

jacques_chester 8y ago
Concourse's components (ATC, DB, Workers) can run on Kubernetes, but it is still handling the scheduling of containers it creates. Delegating container scheduling to Kubernetes is the next major epic on the Core track for Concourse. As for Argo: I am not particularly in favour of Turing-complete YAML. Disclosure: I really like Concourse. I work for Pivotal, which sponsors Concourse development.
- cfontes 8y ago
  Valid point. Don't fly you end up creating a turing-complete config file as well? I remember it being stored as some kind of Yaml like syntax.
  - jacques_chester 8y ago
    Fly does substitutions, but that's it: no loops, no if-thens. It's almost certain that something can be tickled into being Turing-complete; it's actually devilishly difficult to avoid doing it by accident. My hunch is pipelines are Turing complete, but I haven't gotten around to proving it. But there's a difference between trying not to introduce it and going out of your way to build a programming language in YAML. An actual, honest-to-god programmable YAML.
- twic 8y ago
  Wait, doesn't Pivotal also sponsor Turing-complete YAML development?
  - jacques_chester 8y ago
    BOSH v1 manifests were Lovecraftian. Well beyond Turing and into the deep underdark of the Beyondness That Must Not Be Yea Even Unto Enterprise.
cfontes 8y ago
I am no Concourse expert, but I've tried it a couple times. Concourse's interface is just beautiful and functional, the CLI is great as well, but it has it's own ecosystem. Lot's of tools to solve problems that K8s already solves (Jobs, Volumes, resources, scheduling, etc..) it also uses workers which if I remember correctly is just like a scheduled slave which you need to install stuff into. Argo is a different beast, it uses k8s like it should be done in my view. It schedules container to one or multiple k8s Clusters, using CRDs which is kind of a DSL on top of the k8s api. It does not run slaves, is simply a debian or busybox pod, a Job or other resource that runs and returns pakages to the workflow or pass it on. The Syntax, is K8S YAML syntax, the same with a couple more things, very little learning curve if you know K8S YAMLs, Concourse is a very different thing. BTW I have zero to do with Argo, I just find it awesome and am waiting for it to be more stable.
- jacques_chester 8y ago
  > Lot's of tools to solve problems that K8s already solves In fairness, Concourse predates Kubernetes and was invented developed to support a team working on a different container scheduler (Diego, similar vintage to Kubernetes). Otherwise you're right. The pain of carrying around its own container scheduling, worker management etc has been a notably hefty thorn in the side of Concourse for the last two years or so. It should go away as Concourse gets rebased onto Kubernetes. > The Syntax, is K8S YAML syntax, the same with a couple more things, very little learning curve if you know K8S YAMLs, Concourse is a very different thing. As part of my work in and around Knative Build, Topher Bullock and I wrote a little façade Kubernetes controller[0] that lets you send pipelines and see builds from kubectl. Basically it looks like an existing Concourse pipeline, but with the usual k8s boilerplate. I'm not sure what the final Concourse-on-Kubernetes will look like. kubectl is showing one-size-fits-all discomfort (see, for example, knctl[1]) and I am not sold that CRDs are suitable for every purpose. 2018 is clearly The Year of the CRD, so I figure we're about 18 months away from the trough of disillusionment on those. [0] https://github.com/jchesterpivotal/knative-build-pipeline-poc/commits/master https://github.com/jchesterpivotal/knative-build-pipeline-po... [1] https://github.com/cppforlife/knctl https://github.com/cppforlife/knctl

jstrachan 8y ago

Jenkins X can help compete effectively with other tools since it automates your entire CI/CD; from creating the Pipelines, setting up your Environments, creating Preview Environments on each Pull Request and then performing GitOps based promotion through your Environments on each release. I'm looking forward to seeing the Jenkins ecosystem expand to offer similar automated CI/CD for other platforms too (e.g. Terraform / Ansible / VMs etc)

cfontes 8y ago
I saw Jenkins X a few months ago, it indeed looks interesting, I have not used it as it's super new and I don't trust Cloudbees on the super new stuff anymore. I wish you guys all the best and I hope to use it in the future. Talking about right now, if I remember correctly Concourse+Bosh can do a lot of that as well and it's a lot more battle tested so it's not like Jenkins X is all alone there on the "we can do everything" spot but it's refreshing to see it in the fight.