With that said, I'd really like to see better documentation on the Jenkinsfile Pipeline format. I've tried to get started with it a few times, and haven't had tons of success. Stuff like "How do I pull in secrets", and "How do I control a plugin". I appreciate that it's Groovy-based, but that's not particularly helpful information (for a hack like me, at least).
The snippet-generator is nice, but it doesn't necessarily produce working code. Especially for things like getting secrets into a build. And it doesn't give me a broader picture for "How do I even write one of these from an empty text-box".
I recently tried the job-to-Pipeline exporter plugin, and that didn't work on my jobs - it generated stuff that didn't match the input job, and also wasn't structured like the example snippets Jenkins provides natively.
Maybe some kind of a sandbox I could experiment in? Or a REPL or something? It would really help to have something that gave great discoverability, with fast feedback. Faster than I can get by editing a job, saving it, running it, waiting, then realizing I still don't have the syntax right.
Unfortunately, it’s not very easy to do. If you want syntax validation, you can validate it by POSTing to an endpoint on your Jenkins master.
If you want a “sandbox”, you can just replay a pipeline run and make modifications. Both are not very useful IMO and slow down development pace substantially. Don’t get me started on integrating groovy shared libs.
Same here - I really struggled to set up declarative pipelines starting out. The docs don't do a great job of distinguishing between the full groovy syntax and the new declarative syntax and there is a relative dearth of examples.
I think the swiss army knife nature of Jenkins contributes to this - there's just so much you can do.
After working in a team that was heavily using Jenkins files & scripted pipelines I started to believe that writing Jenkins scripted pipelines is a bit of an anti pattern, as you end up with lots of build script code that can only run inside of a Jenkins, perhaps coupled to plugins, which hampers your ability to locally develop and test changes.
Perhaps sometimes using Jenkins scripted pipeline is a good idea, but if you've got the choice of implementing something as a Jenkins pipeline script or some other script that isn't coupled to Jenkins, prefer the latter.
I think as part of the new Jenkins architecture we should be able to make it much easier to stop at a point in a pipeline & open a terminal/REPL to test out steps.
Also I'm hoping for a nice validated YAML based pipeline syntax that should make editing/validating pipelines easier
You can't just use the docs at Apache Groovy's website because Jenkins pipeline uses a crippled version of Groovy -- none of the functional collections-based methods work.
Sandbox, repl, and a testing platform to unit test my Jenkins files are amazing suggestions. Basically an environment I can actually test in, as opposed to write-run-fix
Totally agree. I tried to move our freestyle jobs to pipeline a few times and the experience was horrible. Official documentation was scarce, main concepts not clearly explained, there was barely any example, and god forbid if you use some unpopular plugins because chances are, the plugin does not support pipeline of if it does, good luck finding the syntax for it.
I worked on Jenkins at Lyft and completely set it up for DoorDash. If anybody needs help with their Jenkins setup, hit me up I give free advice and have a few blog posts on the matter.
If you happen to be using AWS, GitHub, and Slack, we at DoorDash have developed lots of goodies for streamlining things. We have secured our Jenkins behind our VPN, created load balanced Jenkins clusters, built a shared Groovy library for all of the Jenkins behaviors that are useful for each of our microservices, implemented a Flask app that receives each of the GitHub webhooks which starts pipelines instantly (rather than git polling), setup Okta integration, interfaced with our internal secrets store, and implemented a way to map GitHub users to Slack users allowing us to Slack message people when they are mentioned in GitHub (when their PR's receive LGTM's etc.) When new microservices launch, Folders automatically appear in Jenkins configured correctly for the service's pipelines.
If any of this sounds good let me know, maybe we open source some of our work. I love working on Jenkins and am happy to help advise you on how to scale, secure, demystify your own Jenkins setup. Links on my HN profile page.
Jenkins's biggest strength is also its biggest weakness: plugins. Any development shop that has been using Jenkins for a while is using at least a bunch of plugins. Plugins are not stable, they break every now and then. They require constant update with new Jenkins versions. They get abandoned by their creators (hell, many plugins still don't support pipeline).
It's a fundamental issue with how Jenkins is set up that I don't know how they can get away with unless they abandon the whole plugin architecture all together. But obviously that's not a solution.
They kind of made several plugins "blessed": Pipeline, Blue Ocean, Git, etc.
The core package plus these "blessed" plugins is a lot more stable than throwing every random plugin on top of a base installation. Just write a bit of glue script code and you're golden.
The deeper issue with plugins is that they create global state across everything.
Switching the execution engine to Kubernetes will help a lot with operational pain. But consider the comparison to Concourse, which also predates Kubernetes. What drove Concourse into being wasn't the lack of Kubernetes (being born during the Diego project, itself a container scheduler), it was the amount of time and pain and unsafety that came from relying on the status quo.
Kawaguchi's agenda is bold and necessary, but I think it's going to take a while to get through even half of it. But the world is better off when Jenkins improves, simply because of its phenomenal installation base. We all talk about Travis and Circle and Drone and Concourse and Gitlab here, but I would bet folding money that over 75% of actual bits going through CI are going through some version of Jenkins.
Disclosure: I work for Pivotal, we sponsor Concourse.
Author of the post. I agree that it is our biggest strength & weakness, I acknowledge that problem and put forward some solutions in the doc.
One piece of the solution is to embrace core and a bunch of important plugins together as the foundation. Normal users shouldn't be asked to pick & choose the basics like that, and we want to lock down the combination of the versions in that group. Whether those are behind the scene plugins or not from contributors' perspective is an implementation detail.
Another piece of the solution is to grow more extensibility mechanism beyond the current in-process plugin. There's a thing called "Pipeline shared libraries" in Jenkins, which is a good example of this. It lets developers create higher level pipeline primitives by composing other existing ones. There's some mechanism to share those with the community, too, although not as sophisticated as plugins. From users' perspective, it extends capabilities of Jenkins just like plugins, but in a way that doesn't create the kind of instability a bad plugin can -- its impact is local to one build, for example.
Then there's the container-as-a-building-block extensibility, Jenkins Evergreen, and more...
I agree this weakness comes from plugins. Because the plugins are not part of the main code base you can't introduce new functionality without breaking them. So you end up with a slow pace of development while you still end up breaking installations on upgrade.
If you add functionality to the main codebase you can keep running your tests to ensure nothing breaks. This is what I think they will do with Cloud Native Jenkins. Essentially abandoning plugins.
Jenkins Evergreen keeps only the essential plugins. This means they can run better tests. And when introducing new functionality you can update the essential plugins.
With GitLab CI we add new functionality in the main code base, avoiding the need for needless configuration and ensuring everything still works when updating.
Part of the ideas mentioned are to resolve this stability, and not depend on in process plugins (a new extensibility architecture that won't hurt stability). There are many things in plugins which should be core functionality (and will be).
yeah, I see 'plugins' being around for a while but docker steps becoming the more cloud native long term alternative; being more reusable stand alone & not requiring changing a Jenkins Master (or even requiring a Jenkins master for ephemeral build pods)
I can't speak for other countries but in London a lot of companies are now using Gitlab or Circle CI.
I migrated all my builds (12 projects) to Gitlab CI. After figuring out the first CI pipeline using DockerInDocker, it was easy to then setup the remaining pipelines.
Self hosting Gitlab was perfect for our needs (private docker registry). I use Gitlab for personal use too.
I wonder if they will get rid of Ruby in the future though and go Java to make it more performant, as it does slow down sometimes.
The Jenkins box is still running though, more out of sentimental value :)
We're working on making GitLab more performant. It is mostly fixes to our code, the parts where ruby is a problem are already rewritten in Go. GitLab self-hosted should be fast if it has enough memory, so make sure you check on its memory consumption.
"in London" suggests that geography is the primary driver of your first-hand experience, rather than tech stack or company type. I've been working in London for a decade, and i don't think i've ever used either Gitlab or CircleCI for CI!
That said, i haven't used Jenkins for several years either.
I was seduced by BlueOcean and tried using Jenkins for CI, using Github and AWS ECS builders (which felt like a common enough use-case).
Unfortunately it ended up costing an astonishing amount of engineering time to get working and maintain, with builds frequently stalled or failing.
Since moving to CircleCI 2.0 enterprise (admittedly far from perfect) and Airflow, we have _dramatically_ reduced eng. time spent managing our job scheduling.
The core of our problem was how fragile and complex the Jenkins ecosystem seems to be: any change to the config or settings and it would easily burn a day of engineering, due to random bugs and hard to understand error messages. In the end, no one wanted to touch it!
I think there's a great project hidden somewhere here, but just getting the basic "everyday" stuff done with it can be a real PITA.
I recognize those challenges in my pitch, we have various efforts already under way to address them, and with this gear shifting, I think we'll be combining those in a compelling way.
For example, defining Jenkins config in YAML in Git is a key piece to solve a fear of config change, and this is called "Jenkins Configuration as Code" and is under way for a while now.
Cloud Native Jenkins will also split single process "master" into many build-as-a-function kind of processes, so it isolates builds and allows changes to be rolled out more incrementally.
There's more focus on us owning a bigger responsibilities around "basic every day stuff," too.
Having used Hudson/Jenkins for many years, I recently considered setting it up for a new project, and backed away mostly due to the issues Kohsuke describes. We ended up choosing GitLab instead.
GitLab has been pulling ahead in features and usability, compared to other things I've tried. Right now, different projects I'm involved with use a combination of GitLab Enterprise, Travis, Circle, and Google Cloud Build. Of those, GitLab accommodates the heaviest and most sophisticated workloads, without having to go through too much trouble to set up, maintain, and instruct developers how to use it (certainly less trouble than Jenkins). I highly recommend taking a critical look at all of these services, to see which best fits your needs.
If you don't mind, I'll shill my service as another option: builds.sr.ht. It's still in closed alpha, but it's being used seriously by several open-source projects for complex build automation. It also deploys itself, here's the build manifest which does it:
If you or anyone else would like to try it, please let me know. I used Jenkins for a long time (and still do at work), Travis for a while as well, also tried Drone and Circle, but none of them were exactly right. I think builds.sr.ht does it very well.
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.
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)
I'm surprised they have such a good understanding of Jenkins' shortcomings. It's a good first step in fixing them. Although to be fair, this has been coming a long time as the post says; but having Cloudbees' CTO publicly acknowledging those is even better.
He's not only Cloudbees CTO, he's the original developer and architect.
And before someone lambasts him for the Jenkins architecture, Jenkins/Hudson was created in 2005, when things were a lot different, and Jenkins managed to create an entire subgenre of software and lead it to the current day. Jenkins hasn't aged gracefully but how many software products from any category have even survived 5 or 10 years? :)
Indeed I wanted to capture the shortcomings correctly, because I truly believe in the power of the community to solve them. Looking at this thread, I feel my summary is largely validated.
We've been working to solve those, and we'll step up even more so. Exciting times!!
The biggest deficiency I found in Jenkins is that GUI-based job configuration is great for simple setups and one-off jobs, but the moment you throw in any sort of parameterization it becomes a real headache. At that point you really need to be able to configure your jobs in code.
I'm wishing Jenkins all the best. I know it since the Hudson times as the de-facto CI system for Java (and Cruise Control before that as my first encounter with CI).
OT: does anybody know a CI system based on plain Makefiles, convention-over-configured for autotools-like default targets, and supporting file-suffix based build and test rules for C + JS + custom compilers and such?
I love working with Jenkins - I know it is a pain to keep up to date but for me it has become a way as a sole or small team syseng to manage all kinds of stuff. "Jenkins-Ansible-Github" where you have a Jenkinsfile sitting in the git repo you are bulding/ deploying etc., has been a pretty good set of tools to manage heterogeneous environments.
I'm impressed about how honest the author is about the shortcomings of Jenkins as it is now. Very appropriate that he mentions being in a local optimum - that is where most organisations end up with Jenkins. The server nearly immediately becomes a snowflake, most stuff is configured through the GUI rather than code, probably some people know it's not ideal but getting to something better requires changing everything and people know how it works now.
Having said that, I think the conclusion is wrong. The next-generation CI already exists (CircleCI, Gitlab, etc), attempting to evolve Jenkins into that seems like a punishing task given the huge legacy and relatively little strategic advantage. Don't want to take anything away from them blazing the trail, but in the same way RCS and CVS did that and eventually bowed out of the game. Jenkins should gracefully do the same.
The worst part of my job is configuring our Jenkins server and managing builds in their dumbass groovy based DSL.
I'm willing to bet that most people just want to build GitHub repos. Then why do we have to do this mess to get a decently repeatable deployment strategy: https://coderanger.net/jenkins/ I should not have to crack open plugin source code in order to configure the plugin programmatically. It's dumb and bad.
Also groovy is a bag language. Managing Jenkins pipeline library deps is a pain.
Also yeah, plugins break constantly and upgrading them is always a nightmare.
At ${DayJob} Jenkins is our default of yore. Returning to refresh a 1.x install for one group's product we're faced with the poster child for a Jenkins install gone bad. Looking at you Chuck Norris plugin. We can't upgrade and we can't migrate to a fresh install due to how Jenkins handles plugins. So we're left with a critical chunk of infrastructure that's a time bomb.
Ultimately instead of making the jump to 2.x and Jenkinsfiles we're trialing Buildkite with great success so far and the confidence that we can jump ship to CloudBuild, TravisCI, Concourse, CircleCI, ect should we need to.
The focus on cloud-first Jenkins is interesting considering Codebees's acquisition of Codeship earlier this year. Obviously Kohsuke would be biased to Jenkins, but as CTO, I'd imagine the corporate goals take precedence.
I'm surprised that I haven't seen more of this announcement in my media streams. I'm not a big fan of Jenkins, I find it overly complex and a Swiss army knife.
When you can do anything, you often end up with poor implementations (IMO). If the tools you have are restrictive but useful enough, I find it easier to adopt my workflow for the tools instead of demanding that my complex workflow fit into this one tool.
I wish we could get encrypted credentials a lá travis in a Jenkinsfile. I’ve found most configuration for a job can be in a git repo but you have to manage some things through the web interface, and it’s not that easy securely managing credentials for a Jenkins installation, even with Folders and Roles
[+] [-] nrclark|7 years ago|reply
With that said, I'd really like to see better documentation on the Jenkinsfile Pipeline format. I've tried to get started with it a few times, and haven't had tons of success. Stuff like "How do I pull in secrets", and "How do I control a plugin". I appreciate that it's Groovy-based, but that's not particularly helpful information (for a hack like me, at least).
The snippet-generator is nice, but it doesn't necessarily produce working code. Especially for things like getting secrets into a build. And it doesn't give me a broader picture for "How do I even write one of these from an empty text-box".
I recently tried the job-to-Pipeline exporter plugin, and that didn't work on my jobs - it generated stuff that didn't match the input job, and also wasn't structured like the example snippets Jenkins provides natively.
Maybe some kind of a sandbox I could experiment in? Or a REPL or something? It would really help to have something that gave great discoverability, with fast feedback. Faster than I can get by editing a job, saving it, running it, waiting, then realizing I still don't have the syntax right.
[+] [-] 0x8BADF00D|7 years ago|reply
If you want a “sandbox”, you can just replay a pipeline run and make modifications. Both are not very useful IMO and slow down development pace substantially. Don’t get me started on integrating groovy shared libs.
[+] [-] andbberger|7 years ago|reply
I think the swiss army knife nature of Jenkins contributes to this - there's just so much you can do.
[+] [-] shoo|7 years ago|reply
Perhaps sometimes using Jenkins scripted pipeline is a good idea, but if you've got the choice of implementing something as a Jenkins pipeline script or some other script that isn't coupled to Jenkins, prefer the latter.
[+] [-] jstrachan|7 years ago|reply
Also I'm hoping for a nice validated YAML based pipeline syntax that should make editing/validating pipelines easier
[+] [-] vorg|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] wgerard|7 years ago|reply
Pipelines can be incredibly rewarding if you spend the time to really dig into it and do a bunch of trial-and-error.
Convincing other people on your team to do that with the current state of documentation is painful, and understandably so.
The documentation really needs a lot of attention.
[+] [-] honkycat|7 years ago|reply
[+] [-] chinhodado|7 years ago|reply
[+] [-] liveoneggs|7 years ago|reply
[+] [-] jonthepirate|7 years ago|reply
If you happen to be using AWS, GitHub, and Slack, we at DoorDash have developed lots of goodies for streamlining things. We have secured our Jenkins behind our VPN, created load balanced Jenkins clusters, built a shared Groovy library for all of the Jenkins behaviors that are useful for each of our microservices, implemented a Flask app that receives each of the GitHub webhooks which starts pipelines instantly (rather than git polling), setup Okta integration, interfaced with our internal secrets store, and implemented a way to map GitHub users to Slack users allowing us to Slack message people when they are mentioned in GitHub (when their PR's receive LGTM's etc.) When new microservices launch, Folders automatically appear in Jenkins configured correctly for the service's pipelines.
If any of this sounds good let me know, maybe we open source some of our work. I love working on Jenkins and am happy to help advise you on how to scale, secure, demystify your own Jenkins setup. Links on my HN profile page.
[+] [-] kohsuke|7 years ago|reply
[+] [-] michaelneale|7 years ago|reply
[+] [-] tbugrara|7 years ago|reply
[+] [-] chinhodado|7 years ago|reply
It's a fundamental issue with how Jenkins is set up that I don't know how they can get away with unless they abandon the whole plugin architecture all together. But obviously that's not a solution.
[+] [-] oblio|7 years ago|reply
The core package plus these "blessed" plugins is a lot more stable than throwing every random plugin on top of a base installation. Just write a bit of glue script code and you're golden.
[+] [-] jacques_chester|7 years ago|reply
Switching the execution engine to Kubernetes will help a lot with operational pain. But consider the comparison to Concourse, which also predates Kubernetes. What drove Concourse into being wasn't the lack of Kubernetes (being born during the Diego project, itself a container scheduler), it was the amount of time and pain and unsafety that came from relying on the status quo.
Kawaguchi's agenda is bold and necessary, but I think it's going to take a while to get through even half of it. But the world is better off when Jenkins improves, simply because of its phenomenal installation base. We all talk about Travis and Circle and Drone and Concourse and Gitlab here, but I would bet folding money that over 75% of actual bits going through CI are going through some version of Jenkins.
Disclosure: I work for Pivotal, we sponsor Concourse.
[+] [-] kohsuke|7 years ago|reply
One piece of the solution is to embrace core and a bunch of important plugins together as the foundation. Normal users shouldn't be asked to pick & choose the basics like that, and we want to lock down the combination of the versions in that group. Whether those are behind the scene plugins or not from contributors' perspective is an implementation detail.
Another piece of the solution is to grow more extensibility mechanism beyond the current in-process plugin. There's a thing called "Pipeline shared libraries" in Jenkins, which is a good example of this. It lets developers create higher level pipeline primitives by composing other existing ones. There's some mechanism to share those with the community, too, although not as sophisticated as plugins. From users' perspective, it extends capabilities of Jenkins just like plugins, but in a way that doesn't create the kind of instability a bad plugin can -- its impact is local to one build, for example.
Then there's the container-as-a-building-block extensibility, Jenkins Evergreen, and more...
[+] [-] victorin|7 years ago|reply
[+] [-] sytse|7 years ago|reply
If you add functionality to the main codebase you can keep running your tests to ensure nothing breaks. This is what I think they will do with Cloud Native Jenkins. Essentially abandoning plugins.
Jenkins Evergreen keeps only the essential plugins. This means they can run better tests. And when introducing new functionality you can update the essential plugins.
With GitLab CI we add new functionality in the main code base, avoiding the need for needless configuration and ensuring everything still works when updating.
I have just written a more extensive analysis of the blog post in https://about.gitlab.com/2018/09/03/how-gitlab-ci-compares-w...
[+] [-] michaelneale|7 years ago|reply
[+] [-] tiny-dancer|7 years ago|reply
[+] [-] jstrachan|7 years ago|reply
[+] [-] mothsonasloth|7 years ago|reply
I can't speak for other countries but in London a lot of companies are now using Gitlab or Circle CI.
I migrated all my builds (12 projects) to Gitlab CI. After figuring out the first CI pipeline using DockerInDocker, it was easy to then setup the remaining pipelines.
Self hosting Gitlab was perfect for our needs (private docker registry). I use Gitlab for personal use too.
I wonder if they will get rid of Ruby in the future though and go Java to make it more performant, as it does slow down sometimes.
The Jenkins box is still running though, more out of sentimental value :)
[+] [-] sytse|7 years ago|reply
I just wrote an article in response to the OP https://about.gitlab.com/2018/09/03/how-gitlab-ci-compares-w...
We're working on making GitLab more performant. It is mostly fixes to our code, the parts where ruby is a problem are already rewritten in Go. GitLab self-hosted should be fast if it has enough memory, so make sure you check on its memory consumption.
[+] [-] twistadias|7 years ago|reply
[+] [-] twic|7 years ago|reply
That said, i haven't used Jenkins for several years either.
[+] [-] rosshemsley|7 years ago|reply
Unfortunately it ended up costing an astonishing amount of engineering time to get working and maintain, with builds frequently stalled or failing.
Since moving to CircleCI 2.0 enterprise (admittedly far from perfect) and Airflow, we have _dramatically_ reduced eng. time spent managing our job scheduling.
The core of our problem was how fragile and complex the Jenkins ecosystem seems to be: any change to the config or settings and it would easily burn a day of engineering, due to random bugs and hard to understand error messages. In the end, no one wanted to touch it!
I think there's a great project hidden somewhere here, but just getting the basic "everyday" stuff done with it can be a real PITA.
[+] [-] kohsuke|7 years ago|reply
I recognize those challenges in my pitch, we have various efforts already under way to address them, and with this gear shifting, I think we'll be combining those in a compelling way.
For example, defining Jenkins config in YAML in Git is a key piece to solve a fear of config change, and this is called "Jenkins Configuration as Code" and is under way for a while now.
Cloud Native Jenkins will also split single process "master" into many build-as-a-function kind of processes, so it isolates builds and allows changes to be rolled out more incrementally.
There's more focus on us owning a bigger responsibilities around "basic every day stuff," too.
[+] [-] ak217|7 years ago|reply
GitLab has been pulling ahead in features and usability, compared to other things I've tried. Right now, different projects I'm involved with use a combination of GitLab Enterprise, Travis, Circle, and Google Cloud Build. Of those, GitLab accommodates the heaviest and most sophisticated workloads, without having to go through too much trouble to set up, maintain, and instruct developers how to use it (certainly less trouble than Jenkins). I highly recommend taking a critical look at all of these services, to see which best fits your needs.
[+] [-] Sir_Cmpwn|7 years ago|reply
https://git.sr.ht/~sircmpwn/builds.sr.ht/tree/.build.yml
And an example of a build which used it:
https://builds.sr.ht/~sircmpwn/job/6974
If you or anyone else would like to try it, please let me know. I used Jenkins for a long time (and still do at work), Travis for a while as well, also tried Drone and Circle, but none of them were exactly right. I think builds.sr.ht does it very well.
[+] [-] cfontes|7 years ago|reply
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.
[+] [-] jstrachan|7 years ago|reply
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)
[+] [-] twic|7 years ago|reply
https://github.com/helm/charts/tree/master/stable/concourse
[+] [-] Aissen|7 years ago|reply
[+] [-] oblio|7 years ago|reply
And before someone lambasts him for the Jenkins architecture, Jenkins/Hudson was created in 2005, when things were a lot different, and Jenkins managed to create an entire subgenre of software and lead it to the current day. Jenkins hasn't aged gracefully but how many software products from any category have even survived 5 or 10 years? :)
[+] [-] kohsuke|7 years ago|reply
Indeed I wanted to capture the shortcomings correctly, because I truly believe in the power of the community to solve them. Looking at this thread, I feel my summary is largely validated.
We've been working to solve those, and we'll step up even more so. Exciting times!!
[+] [-] lima|7 years ago|reply
Authentication, SSH secrets and - most importantly - running each build in an ephemeral pod works out of the box.
https://docs.openshift.com/container-platform/3.9/dev_guide/...
[+] [-] curtis|7 years ago|reply
[+] [-] tannhaeuser|7 years ago|reply
OT: does anybody know a CI system based on plain Makefiles, convention-over-configured for autotools-like default targets, and supporting file-suffix based build and test rules for C + JS + custom compilers and such?
[+] [-] mbubb|7 years ago|reply
[+] [-] Thaxll|7 years ago|reply
[+] [-] CamouflagedKiwi|7 years ago|reply
Having said that, I think the conclusion is wrong. The next-generation CI already exists (CircleCI, Gitlab, etc), attempting to evolve Jenkins into that seems like a punishing task given the huge legacy and relatively little strategic advantage. Don't want to take anything away from them blazing the trail, but in the same way RCS and CVS did that and eventually bowed out of the game. Jenkins should gracefully do the same.
[+] [-] honkycat|7 years ago|reply
I'm willing to bet that most people just want to build GitHub repos. Then why do we have to do this mess to get a decently repeatable deployment strategy: https://coderanger.net/jenkins/ I should not have to crack open plugin source code in order to configure the plugin programmatically. It's dumb and bad.
Also groovy is a bag language. Managing Jenkins pipeline library deps is a pain.
Also yeah, plugins break constantly and upgrading them is always a nightmare.
[+] [-] baylisscg|7 years ago|reply
Ultimately instead of making the jump to 2.x and Jenkinsfiles we're trialing Buildkite with great success so far and the confidence that we can jump ship to CloudBuild, TravisCI, Concourse, CircleCI, ect should we need to.
[+] [-] bdcravens|7 years ago|reply
[+] [-] toredash|7 years ago|reply
When you can do anything, you often end up with poor implementations (IMO). If the tools you have are restrictive but useful enough, I find it easier to adopt my workflow for the tools instead of demanding that my complex workflow fit into this one tool.
[+] [-] batbomb|7 years ago|reply
[+] [-] slavik81|7 years ago|reply