71–80 of 157 posts
Jenkins by itself is eating too much memory on our buildservers, which can be used more wisely. Using compiled language could help that - e.g. Drone.io CI written in Go: https://drone.io/ You can find it's sources here: https://github.com/drone/drone I just hope it would be able to work without docker, like jenkins.
It is clear that build stages should be first class citizens. We based GitLab CI on the awesome work that GoCD and Concourse did in this respect. Our DSL allows you to assign jobs to stages https://gitlab.com/gitlab-org/gitlab-ce/blob/43e49f52e30199c... and jenkins seems to have picked a similar syntax. What is interesting is that Jenkins has a DSL but that this is not part of the repository. This means that it is ha…
Almost all of what you said here is totally wrong. >What is interesting is that Jenkins has a DSL but that this is not part of the repository. Netflix job dsl plugin, Jenkinsfile pipleline, dotci all of these let you put a .travis.yml like file in your repo. >But the plugins have access deep into the Jenkins internals, preventing a rewrite of core functionality. Plugins don't have deep access to jenkins internals the…
1. Cool that there are different plugins that let you check the configuration in a dotfile.
2. I was not aware they used extension points instead of something more intrusive.
3. Obviously I like GitLab and try to promote it. But I post this too to see what others think and to learn. Turns out I had a lot to learn in this case. I still think that some items in Jenkins should be part of the core, such as the pipeline. But I agree that plugins are needed for some cases. For deploys we're thinking about plugins for GitLab CI too in https://gitlab.com/gitlab-org/gitlab-ce/issues/3286#note_402...
Jenkins by itself is eating too much memory on our buildservers, which can be used more wisely. Using compiled language could help that - e.g. Drone.io CI written in Go: https://drone.io/ You can find it's sources here: https://github.com/drone/drone I just hope it would be able to work without docker, like jenkins.
Jenkins too is built on top of a compiled language. Too bad it is JVM, which is a hog when it comes to memory... Point being that a "compiled language" is no guarantee of a low memory usage.
I've been using Jenkins for years, and have been overwhelmingly happy. 2.0 is a big step for the project, congrats! The flexibility Jenkins provides as build system is enormous. The plugin community is also a huge benefit -- chances are, if you have a need, there's a plugin for it.
Jenkins by itself is eating too much memory on our buildservers, which can be used more wisely. Using compiled language could help that - e.g. Drone.io CI written in Go: https://drone.io/ You can find it's sources here: https://github.com/drone/drone I just hope it would be able to work without docker, like jenkins.
Earlier quoted context omitted.
Yeah, version control of Jenkins itself has always scared me. There seems to be a pattern that we go through. (in the beginning, there was light...) * Create a small, tight, single-purpose Jenkins job * Add a small tweak to it (repeat adding tweaks) (realize the Jenkins job now contains MANY different configurations options and the job itself is now a shell script in its own right) * Sweep the "job" into a shell scri…
We use Netflix's Job-DSL to keep Jenkins job configuration in source control (and to allow easier reuse than offered with job reuse plugins). https://github.com/jenkinsci/job-dsl-plugin
Earlier quoted context omitted.
"Heaps in the 1-2 GB range are not uncommon." Is this really still a complaint in 2016? Your phone has that much RAM. Honestly if you're worried about Java heap size, spin up a t2.medium instead of a t2.small for your build pipeline. Running Jenkins on a Raspberry Pi is probably not a great idea if you're writing any serious application.
Actually it's becoming more of a complaint in 2016 with rise AWS instances that pay by the container size and with the rise of languages like go, etc. which have smaller runtime sizes and are more compatible with cloud computing environments like docker. The JVM adds something like 400MB to every layer of a docker container resulting in multi gigabyte containers. Additionally the memory requirements for running a JVM…
Perhaps this is the "writing on the wall" that containers aren't what you should be using to deploy your app.
Just because it's the "latest craze" doesn't mean it's the best solution for the task at hand.
Earlier quoted context omitted.
The DSL can pull in other scripts from elsewhere, so you could just have a stub Jenkinsfile in your project, with the bulk of the pipeline config version-controlled in another repo.
And if I change where I keep my pipeline config, I have to commit a change to the project so it grabs it from the new place? Or pass it in as a parameter, so you need to know ahead of time what parameters the DSL will be expecting? Come on now, we don't need to go to these contortions just to avoid saying that Jenkins is doing it wrong.
You could indeed just use the Jenkinsfile for building a project. You can also specify the DSL config directly in a job, e.g. in a separate deployment job.
What would be the right place to define the deployment config?
So given that's the foundation they're layering even more complicated stuff on top of it. Thanks but I'll pass.
Earlier quoted context omitted.
the config is a huge problem, not just because of XML files. Jenkins (pre 2.0 at least) job configs have huge problems with config drift and doesn't play well with configuration management tools. Trying to automate jenkins job configurations requires using the terrible job config xml format and a poorly designed rest API which breaks all the time when you add in a plugin or plugins get upgraded.
Then this should be a life saver for this scenario: https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin Jenkins has a ton of issues but with a bit of careful plugin selection it provides a ton of bang for your buck.