Jenkins Script Console and some Groovy Scripts

I am one of those jenkins users who use Jenkins Script Console  [1] extensively. I have been maintaining some of those scripts in a private repository, lately I came across this gist [2] by Damien Nozay which uses a much simpler way to share these scripts i.e. using gists :D
After forking it I have started adding my scripts in gists as well   https://gist.github.com/mubbashir/484903fda934aeea9f30 [3].

I found it quite useful e.g. lately I need to know the results of all the downstream jobs triggered by a certain job:
https://gist.github.com/mubbashir/#file-jobstatustriggeredbyupstreamcause

/ author : Ahmed Mubbashir Khan
// Licensed under MIT
// ---------------------------------------------------------
// This script prints out information of last dwonstream job of Upstream job
// e.g. printInformationOfDownstreamJobs("ChangeListner", 11, "All Tests")
// will print all the downstream jobs invodked by ChangeListner build 11 in the view "All Tests"
// ---------------------------------------------------------

import hudson.model.*
//printInformationOfDownstreamJobs("ChangeListner", 11, "All Tests")

def printInformationOfDownstreamJobs(jobName, buildnumber, viewName){
  def upStreamBuild = Jenkins.getInstance().getItemByFullName(jobName).getBuildByNumber(buildnumber)
  println "${upStreamBuild.fullDisplayName}" +
   "${upStreamBuild.getCause(hudson.model.Cause.UpstreamCause).upstreamRun}"
  def cause_pattern = /.*${jobName}.*${buildnumber}.*/
  println "Cause pattern: ${cause_pattern}"
  // Upated for any builds of the upstream  job in a view from only the last build
  def view = Hudson.instance.getView(viewName)
  def buildsByCause = []
   // For each item in the view 
  view.getItems().each{ 
    def jobBuilds=it.getBuilds() // get all the builds 
    jobsBuildsByCause = jobBuilds.findAll { build ->    
    build != null &&
    build.getCause(hudson.model.Cause.UpstreamCause)!= null &&
    build.getCause(hudson.model.Cause.UpstreamCause).upstreamRun==~cause_pattern
    }
    buildsByCause.addAll(jobsBuildsByCause)
  }
   // printing information 
  buildsByCause.each{ d_build->
   // def d_build = job.lastBuild
    println("Build: ${d_build.fullDisplayName}->"+
     "result:${d_build.result}->${d_build.buildStatusSummary.message}, " +
     "(was triggered by:${d_build.getCause(hudson.model.Cause.UpstreamCause).upstreamRun})" )
  }
}




Or information about the builds in a new e.g. node on  which they were executed along with the time they took:
https://gist.github.com/mubbashir/#file-jobs-in-view-with-duration-label-groovy 

// author : Ahmed Mubbashir Khan
// ---------------------------------------------------------
// This script goes through all the jobs in a view, filters succesful and failed jobs seprately
// Then prints outs them along with the time they took
// ---------------------------------------------------------
import hudson.model.*
def str_view = "Pipeline Tests"
def view = Hudson.instance.getView(str_view)
def successfulJobs = view.getItems().findAll{job -> job.lastBuild != null && job.lastBuild.result == hudson.model.Result.SUCCESS}
def faildJobs = view.getItems().findAll{job -> job.lastBuild != null && job.lastBuild.result == hudson.model.Result.FAILURE}
def disabledJob = view.getItems().findAll{job -> job.disabled == true}
def enabledJob = view.getItems().findAll{job -> job.disabled != true}
println "Total jobs: " + view.getItems().size +" Successful: " +successfulJobs.size+
  " Failed: " + faildJobs.size + " Enabled jobs: " +enabledJob.size + " Disabled jobs: " +disabledJob.size 
println "Current Successful job:"
successfulJobs.each{job -> printInfo(job)}
println "Current Fail job:"
faildJobs.each{job -> printInfo(job)}
println "Current disabled job:"
disabledJob.each{job -> printInfo(job)}
println "Current enabled job:"
enabledJob.each{job -> printInfo(job)}

def printInfo(job){
  println "Job: ${job.name} build on ${job.getAssignedLabelString()}, "+
    "took ${job.lastBuild.getDurationString()} to build, is disabled : ${job.disabled}"
}

[1] https://wiki.jenkins.io/display/JENKINS/Jenkins+Script+Console
[2] https://gist.github.com/dnozay/e7afcf7a7dd8f73a4e05
[3] https://gist.github.com/mubbashir/484903fda934aeea9f30 

Update:
Updated https://gist.github.com/mubbashir/#file-jobstatustriggeredbyupstreamcause to list any downstream job which matches and upstream cause

Jenkins: List all the jobs for which SCM is not currently configured

Put the following in  Jenkins Script Console  to  list all the jobs for which SCM is not currently configured:

// Licensed under MIT
// author : Ahmed Mubbashir Khan
// ---------------------------------------------------------
// This script goes through all the jobs and checks if they configured SCM is hudson.scm.NullSCM
// if they are, then prints it's info
// ---------------------------------------------------------
 

counter = 0
jobs = Jenkins.instance.getAllItems()
for (job in jobs) {
  if (job.scm instanceof hudson.scm.NullSCM){
    println "Job= '${counter++}' '${job.name}' scm '${job.scm}'"
  }
}

Adding pre-commit (package) to git repo of your python projects

Git pre commits  are quite useful to analyze  the code before you make a commit and pre-commit makes it quite easy to mange these hooks and rules to run via these hooks.

• Install pre-commit, pip install pre-commit ## detailed instruction  on it's website pre-commit
• Run pre-commit install ## Usage instruction  on it's website pre-commit
• Create .pre-commit-config.yaml file in your project root
• I have added it to  behave-selenium, check it out

pre-commit install will install pre-commit into your git hooks, now on words it will be run on every commit. 

Every time you clone a  project running pre-commit install should always be the first thing you do.

The first time pre-commit runs on a file it will automatically download, install, and run the hook. Note that running a hook for the first time may be slow. 

• To Run all pre-commit manually on all file type pre-commit run --all-files
• To run specific hook (via the id in .pre-commit-config.yaml) on specific file(s) pre-commit run autopep8-wrapper --files features/steps/google_steps.py

We can also run all the pre commit hook as a CI step e.g. pre-commit run --all-files 

Individual tools can configure in accordance to according to there configuration. For example flake8 can be configured by adding a setup.cfg file 

Changing Subversion credentials in Hudson

I was in a need of changing the Credentials of subversion for a project, unfortunately i was not able to find any straight forward link in manage panel. So the Quick hack to achieve this is:

1. go to http://[Hudson_Home]/hudson/scm/SubversionSCM/enterCredential
2. Enter the URL of subversion repository
   
3. Click on Username/password authentication
4. Enter User name and password for the repository
5. press OK

thats it.

Evaluating Continuous Integration: Itself

I am not writing about how to evaluate a CI Server, if one needs to evaluate them the best resource I can suggest is CI Feature Matrix just list out your requirements before going to this page, and see which one is the best fit for you. Just for the idea of current state of CIS see What Continuous Integration Server are you using in 2008?.

Evaluating CI Server is not the important part: Once we have decided that we will have a CI server in-place, personally I don't think evaluating the CI server is the important part , I have played with quite a few continues integration servers (just to name a few: cruise control, continum, luntbuild, Hudson and Bamboo), while playing with them I realize that every single one of them dose the same basic thing really well. All of them will check out source from a Source Control Management system, will build the code in one or another way and will run/publish results of your tests. ITs what you want to do with the CI server.

The Important Part, Evaluating Continuous Integration: Yeah we need to Evaluate Continuous Integration Itself. Continuous Integration is not just an activity or state but a Philosophy, a culture which is foster by agile methodology, to integrate and test the code more frequently to find out bugs when it’s less expensive to fix them. Are you and your team comfortable with it? Have you spend enough time with the team to let them know the importance and advantages of it? have you trained them how will they carry out there work from now onwards? are you keeping an eye on the state of builds? are people writing Unit Tests at the very first place? and so on.. make your self comfortable with Continuous Integration.

Open Source To rescue: Don't invest on any commercial tool straight away just because you think it will be cool, its not a tool you are looking for its the process. Use open source tools to introduce CI, to prepare your team for CI (you might like the open source alternatives so much that you might stick to them) make CI a part of development cycle and "Evaluate CI for your team and your team for CI". This will help you to refine requirements but more importantly you will know who needs the Improvement they way CI is being conducted or your team. This Evaluating CI can be done in two possible ways: 1. By using complete open source solution: (e.g Hudson with code analysis tools like cobertura, PMD and FindBugs) 2. By using Evolutionary copy of a commercial CI Server: (e.g Bamboo with code analysis tools like clover/ cobertura, PMD and FindBugs)

What are your waiting for Start Evaluating...

Need to know about Continuous Integration go to Martin Fowler Continuous Integration or buy Continuous Integration: Improving Software Quality and Reducing Risk (Addison-Wesley Signature Series)