Bash is very good when the problem is solved by running unix commands. Learning bash is key, and I strongly recommend the O'Reilly book "Learning the bash shell". The bash shell is mature and even if the book does not cover bash 4, all the fundamentals are there. I can recommend three sites for bash: http://mywiki.wooledge.org/EnglishFrontPage http://wiki.bash-hackers.org/doku.php http://tldp.org/LDP/abs/html/
Exit codes are easy to master. An exit code of zero means the command has "passed", anything else means the command has failed somehow. For example: make my_target if [[ $? -ne 0 ]]; then ret=1 echo "Make has failed" >&2 fi I keep all my problems in the pass/fail category, and I never try to interpret non-zero exit codes because it gets too complicated. However it is key that any script underneath returns an exit code to its caller, all the way up to Jenkins, so make sure your Jenkins build step has an exit statement with an exit code that represents the "worst" error reported underneath. If you use pipes, you should always use "set -o pipefail". This will make sure that the pipe will not hide a failure (see man bash): $ (exit 1 | echo "hi") hi $ echo $? 0 $ set -o pipefail $ (exit 1 | echo "hi") hi $ echo $? 1 Now regarding Jenkins, when you have a parametrized build, Jenkins exports those parameters as shell variables that match your parameter names. You can see them in the console by adding the "env" command to your free style build. Also I recommend you always use the shebang to start your free style build (Jenkins will run your script with the -e option, but there are too many exceptions to "set -e", so I just use #!/bin/bash, see: http://mywiki.wooledge.org/BashFAQ/105) If you background jobs, you will need to keep track of their process ids, for example set a trap: function onKill { kill $pid ... other clean up you might want to do goes here } ./my_script & pid=$! trap 'onKill; exit 1;' SIGINT SIGTERM wait $pid if [[ $? -ne 0 ]]; echo "my_script failed" &2 fi You will also need to generate JUnit XML reports in the format that Jenkins understand. Java is not the language of my builds, and it was very painful to figure out what Jenkins supported. It was a lot of trial an error, and there are many unclear explanations on the internet. I ended up with something similar to this: http://pzolee.blogs.balabit.com/2012/11/jenkins-vs-junit-xml-format/ My bash build step does not generate XML reports, but commands inside GNU Make, which is called by my script, do (it is actually many layers below the Jenkins "script window" in my case). Last advice, keep the code in the build phase window to the bare minimum: put all the smarts in a script that Jenkins calls instead. This way you don't have to copy and paste bug fixes when you have the same script in multiple builds: you simply fix the script that Jenkins calls. Bash is very powerful if you learn it well. If you need to manipulate data structures, then you will need to move up to a higher level language like python, but if all your build does is call commands and watch exit codes, bash will do the job really well. Good luck. -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
