So we use Jenkins at work, and I'd like to really learn how it works, particularly so I could customize our builds with Jenkins' flavor of Groovy scripts, understand what all of the build scripts mean, etc. But I just can't seem to find any solid, up-to-date documentation. Here's where I've looked so far:
I've read "Jenkins: The Definitive Guide" -- this is good as far as it goes, but it's outdated (2011) and doesn't seem to cover many of the current Jenkins features
The documentation on jenkins.io -- this is pretty minimal and clearly a work in progress
The wiki at wiki.jenkins-ci.org -- this has more information than jenkins.io, but seems to be mostly focused articles on specific topics, without a comprehensive discussion of how it all works
Stack Overflow -- there are a few questions on Jenkins documentation for specific use cases (e.g. writing a plugin), but as far as I can tell, none of those answers point to general, comprehensive documentation
I feel like I must be just missing something, since so many people use Jenkins -- they must be figuring out how to use it somehow.
Jenkins has a lot of plugins and generally I would google the plugin you intend to use.
I found some documentation about the pipeline plugin on jenkins.io and there is a lot more documentation there. If you want to accomplish something that you can't find there again try to google or ask here :)
I have found the Jenkins Handbook very useful. I would say it's got a lot of good information packed into 150 pages.
Due to the numerous implementation possibilities with Jenkins, it makes it somewhat difficult to fully document every possible use case.
Related
This is sort of an open-ended question/request (hope that's allowed).
On my team we are using Karate API testing for our project, which we love. The tests are easy to write and fairly understandable to people without coding backgrounds. The biggest problem we're facing is that these API tests have some inherent degree of flakiness (since the code we're testing makes calls to other systems). When running the tests locally on my machine, it's easy to see where the test failed. However, we're also using a Jenkins pipeline, and when the tests fail in Jenkins it's difficult to see why/how they failed. By default we get a message like this:
com.company.api.OurKarateTests > [crossdock] Find Crossdock Location.[1:7] LPN is invalid FAILED
com.intuit.karate.exception.KarateException
Basically all this tells us is the file name and starting line of the scenario that failed. We do have our pipeline set up so that we can pass in a debug flag and get more information. There are two problems with this however; one is that you have to remember to put in this flag in every commit you want to see info on; the other is that we go from having not enough information to too much (reading through a 24MB file of the whole build).
What I'm looking for is suggestions on how to improve this process, preferably without making changes to the Jenkins pipeline (another team manages this, and it will likely take a long time). Though if changing the pipeline is the only way to do this, I'd like to know that. I'm willing to "think outside the box" and entertain unorthodox solutions (like, posting to a slack integration).
We're currently on Karate version 0.9.3, but I will probably plan to upgrade to 0.9.5 as part of this effort. I've read a bit about the changes. Would the "ExecutionHook" thing be a good way to do this? I will be experimenting with this on my own a bit.
Have other teams/devs faced this issue? What were your solutions? Again we really love Karate, just struggling with the integration of it to Jenkins.
Aren't you using the Cucumber Reporting library as described here: https://github.com/intuit/karate/tree/master/karate-demo#example-report
If you do - you will get an HTML report with all traffic (and anything you print) in-line with the test-steps, and of-course error traces, and most teams find this sufficient for build troubleshooting, there is no need to dig through logs.
Do try upgrade as well, because we keep trying to improve the usefulness of the logs, and you may see improvements if you had failed in a JS block or karate-config.js.
Else, yes the ExecutionHook would be a good thing to explore - but I would be really surprised if the HTML report does not give you what you need.
It is easy to find simple examples for declarative or scripted pipeline. But when the point comes where you go deep into scripting you need so much more information. When you're not familiar to the world of web, java and groovy you are running out of questions which can be asked to go future. Googeling helps you find some magic "hudson.model.Hudson..." or .methods and e.g. #NonCPS-operators solutions. Those solutions work, but I'm searching for the bigger context to work my self from the bottom up. Not from the top down. I'm looking for the knowledge, which is obvious to the insiders.
I'm looking for links/books/api-references or introductions to learn to find the entrance to knowledge around the jenkins scripted pipeline. e.g. like this one =).
I am not looking for answers to those questions below from the stackoverflow communety. This would be to much! I am looking for links of documentation to get deep into the topic. I assume that for an insider it's insider knowledge is not obvious. So I'm stating here some questions to make it obvious what I would describe as insider knowledge.
Example questions:
like : "hudson.model.Hudson..." but where do I get those magical dot.separated strings?
Is there a documentation of the Jenkins Api?
How can I find documentation of the classes and methods usable in jenkins like e.g. X.Y.collect?
Is there a way to debug a pipeline?
Is there a faster way in testing code than every time run it in a pipeline?
How does the inner mechanism work?
Is the Knowledge more about groovy or is it about general Jenkins? Or is it java?
Why println MyArrayList.getClass() class java.util.ArrayList which is a java class? does grooy inherit the types from java, or does the pipeline inherit the types from jenkins, which is java?
...
Asking one question at a time:
where do I get those magical dot.separated strings?
Those are inner java classes at the Jenkins core (or plugins). For the former, Javadoc is available, the latter have their code at Github
classes and methods usable in jenkins
Mostly every Java and Groovy class/method is usable
debug a pipeline?
You can only replay it, issuing changes on each Run
testing
you have two approaches: LesFurets one and the real-unit-one
innards
wide question and wider answer. pipelines are loaded, transformed and run as a near to groovy code (#NonCPS annotation alters this behaviour).
Knowledge about Java, Groovy and Jenkins will apply.
Groovy indeed extends Java hence, both languages apply
I've been doing web programming for some time now, and don't consider myself so much of a total newbie but I still don't understand what "/path/to" is. People use that code a lot, and I used to think it's just a way to refer to main path. But I started wondering why so many people use that syntax so uniformly, because it's confusing if it's meant to be NOT taken literally. Most people would actually type in "/path/to".
So I tried searching for "/path/to" on google, but this is something that's hard to search on a generic search engine, so no luck. So I decided to ask here. Is "/path/to" some kind of jargon that people use to refer to something? If yes, what does it exactly refer to? If no, then how does it work internally?
This is just a placeholder for an actual path in your environment. I usually use it when I want to abstract from the path in question. It does not matter and the reader/user of my code will likely have it different. So I prefer to clearly indicate what places he should amend.
Other examples of this sort:
GET http://example.com
ssh username#host
/path/to/project and similar constructs are used in documentation and blog posts to abstract away details that vary on different machines and for different people. For example, I might be working on a project on my Linux machine that is at /home/code-apprentice/src/my-cool-ruby-project. At the same time, you are working on a project on your Windows machine that you put at C:\Users\Vlad\Projects\MyEvenBetterRubyProject. We both are reading the same blog article to implement a feature. The detail of the exact path where we each store our project doesn't matter for the particular part of Ruby on Rails that we are using. The notation /path/to/project is just a convenient and concise placeholder to describe the root of the project that varies between our machines.
First, brief but profound thanks to all who have responded to my questions to date.
I'm climbing the Erlang OTP learning curve and enjoying every step. Now digging into Application design and integration. My question today is this:
Suppose I have a set of library modules: myLibrary. I want to employ these functions in an Erlang Application involving a set of application-specific modules: myApp. Mylibrary may well serve Applications beyond myApp.
I want, in turn, to deploy myApp over the web, over, on Webmachine, say. I also want need data persistence for myApp, could be Dets or Mnesia or Riak -- yet to be decided.
First, should I wrap myLibrary into the same Application as myApp? Or should they be separate Applications?
Second, how can I best integrate all these Apps into one functional Release? (I'm burning oil on the published docs re: this question, but finding them a bit confusing).
Thank you,
LRP
First of all, I'm thrilled that you are learning erlang and getting your questions answered by the community. I would like to suggest, however, that you reciprocate the good will by marking correct answers that we have provided as "accepted". Now that we have that out of the way, on to the actual answer...
myLibrary should be it its own repository if you believe it has potential for reuse. See edate as an example of such a library.
I agree that the business of packaging applications and their dependencies in erlang is, at the moment, a bit confusing. You may want to start with my answers here and here.
This set of three posts walks you through the process of integrating the holy trinity of webmachine, erlydtl, and riak. The material is a bit dated but as I recall the author touches on a number of points pertinent to your question.
This post is often given as a reference for using rebar and creating actual releases.
As of this writing I don't actually do real erlang releases in production. I use rebar to compile, test, and manage my dependencies and that's it - on my production servers I just clone my repository, run make, and away I go. But if you want the full-on release management experience, rebar can help you do that too.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
One thing I really miss about Java is the tool support. FindBugs, Checkstyle and PMD made for a holy trinity of code quality metrics and automatic bug checking.
Is there anything that will check for simple bugs and / or style violations of Ruby code? Bonus points if I can adapt it for frameworks such as Rails so that Rails idioms are adhered to.
I've recently started looking for something like this for Ruby. What I've run across so far:
Saikuro
Roodi
Flog
These might be places to start. Unfortunately I haven't used any of the three enough yet to offer a good opinion.
Saikuro and Flog can be good for getting a basic idea of code complexity. You can also use a tool like rcov to look at your test coverage.
There is a plugin for Rails projects that combine all those metrics into a single rake task. It is called metric_fu.
Projects I've found and tested recently:
https://github.com/railsbp/rails_best_practices
Seems to work, and gives sensible warnings
https://github.com/simplabs/excellent
Works, but quite a few false positives
https://github.com/troessner/reek
I disagree with most of the warnings from this tool, but it works
http://www.cs.umd.edu/projects/PL/druby/
This requires ocaml; I haven't tried it, but it looks like it might be good
http://roodi.rubyforge.org/
does not appear to be Ruby 1.9 compatible
https://github.com/gdb/ruby-static-checker
Is broken for me, and only catches name errors, so unit tests should cover that.
https://github.com/michaeledgar/laser
Doesn't compile for me
You might want to try out RuboCop. It is a Ruby code style checker based on the Ruby Style Guide. It's maintained pretty actively and it's based on standard Ruby tooling (like the ripper library). It works well with Ruby 1.9 and 2.0 and has great Emacs integration. I hope you'll find it useful!
Dust looks like it can help you find unused and useless code, which seems like it sort-of fits what you're after.
I'm not aware of any other such tools.
This problem is vastly harder to address in ruby than it is in java - you'll note that all those java tools brand themselves as using 'static analysis' of the code.
Static analysis of ruby code often isn't possible, because there isn't anything static that you can analyze (methods often get created at runtime and so on)
At any rate, some of these things are unneeded in ruby because the language builds them in.
For example, you don't need a coding standard to enforce that your classes are all NamedLikeThis because the code won't work if they aren't.
P.S. I have to add the standard disclaimer that those kind of tools can often be a bit of a red herring. You can spend all day making your code adhere to what the tool thinks it should be, and end up with more bugs than you started with.
IMHO the best solution is to write your code fluently so you can read it more easily. No amount of static analysis is going to be as good as a human reading code which clearly states what it is meant to do. Being able to do this is where ruby is light-years ahead of many other languages. I personally would recommend you aim your efforts at learning how to write more fluently, and educating your team about such things, than spending time on static analysis.
Another nice tool, although in early stages according to the author is reek:
http://reek.rubyforge.org/
reek currently includes very naive checks for the following code smells:
Long Method
Large Class
Feature Envy
Uncommunicative Name
Long Parameter List
Utility Function
Nested Iterators
Control Couple
Duplication
List item
Personally I think it still has too much false positives, but just looking at the output in some of my code helped me rethink some decisions about code style and architecture.
Code Climate is a SaaS tool that integrates through git and automatically "grades" your code. It notifies you via various channels if there a sudden drop in quality. Nice UI as well.
I didn't see this questions when asked, but a blog post I did might help as well. In it I cover a bunch of Ruby tools and specifically cover 4 code quality tools...
Roodi
Dust
Flog
Saikuro
It might also be worth checking out Towelie and Flay
http://devver.wordpress.com/2008/10/03/ruby-tools-roundup/
Now we have combined a lot of tools into an only Ruby code quality and metrics monitoring tool called Caliper. This might fit your needs well. It tracks various quality metrics over the life of a project.
Caliper - improve your Ruby code
There is also excellent. I haven't tried it yet, but it too looks promising.