jenkins_api_client 0.12.1 → 0.13.0

data/.travis.yml

@@ -21,6 +21,8 @@ before_install:
 script:
   - bundle exec rake unit_tests
   - bundle exec rake func_tests
+  - travis/setup_crumb.sh
+  - bundle exec rake func_tests
 notifications:
   email: false
   irc:

data/CHANGELOG.md

@@ -4,6 +4,35 @@ CHANGELOG
 upcoming
 --------
 
+v0.13.0  [09-JUL-2013]
+----------------------
+* Jenkins XSS disable option is now supported. No inputs are required - the
+  jenkins_api_client will automatically detech whether to use the crumbs or not
+  when making the POST requests.
+* Support for logging is added. Logs can be redirected to a log file and the
+  log level can be customized. This implementation uses the `Logger` class so
+  it follows the nice format in logging messages.
+* The job `build` method will now optionally return the build number. This
+  option should be used with care as the build method will wait till the
+  jenkins job is placed on an executor from the build queue. By default the
+  build number will NOT be returned. nil will be returned if the build number
+  is not available. Also a Timeout error will be raised if the job waits in the
+  queue for longer than the 'timeout' parameter. This timeout parameter can be
+  set during the client initialization.
+* Improved documentation
+* Support for enabling/disabling jobs. Credit: @dieterdemeyer
+* Added functionality for copying jobs. Credit: @dieterdemeyer
+* Added functionality for wiping out the workspace of a job.
+  Credit: @dieterdemeyer
+* Added functionality for listing jenkins users. Credit: @dieterdemeyer
+* Fixed a bug where the exceptions where not thrown when using the
+  `get_console_output` method.
+* Fixed a bug where the jenkins_path attribute was ignored when the server_url
+  input argument is given. Credit: @woodbusy
+* support public/private key pair authentication for Jenkins CLI.
+  Credit: @missedone
+
+
 v0.12.1  [25-JUN-2013]
 ----------------------
 * Fixed a bug where the SSL support was not working properly with Ruby
@@ -27,7 +56,7 @@ v0.12.0  [18-JUN-2013]
   This was resulting in an exception and the exception handling is modified to
   handle this condition.
 * The jobs that are not built yet have a new color (`notbuilt`) in the recent
-  version of jenkins (> 1.517) whih resulted in `invalid` status. This is fixed.
+  version of jenkins (> 1.517) which resulted in `invalid` status. This is fixed.
 
 v0.11.0  [09-JUN-2013]
 ----------------------

data/CONTRIBUTORS.md

@@ -0,0 +1,13 @@
+Thank you very much to all who contributed to this project.
+
+* [Niarfe](https://github.com/Niarfe)
+* [dieterdemeyer](https://github.com/dieterdemeyer)
+* [kevinhcross](https://github.com/kevinhcross)
+* [drnic](https://github.com/drnic)
+* [woodbusy](https://github.com/woodbusy)
+* [missedone](https://github.com/missedone)
+* [cylol](https://github.com/cylol)
+* [madisp](https://github.com/madisp)
+* [rubytester](https://github.com/rubytester)
+* [dougforpres](https://github.com/dougforpres)
+* [brettporter](https://github.com/brettporter)

data/README.md

@@ -17,20 +17,18 @@ Google Group: https://groups.google.com/group/jenkins_api_client
 
 OVERVIEW:
 ---------
-This project is a simple API client for interacting with Jenkins Continuous Integration server.
-Jenkins provides three kinds of remote access API. 1. XML API, 2. JSON API, and 3. Python API.
-This project aims at consuming the JSON API and provides some useful functions for controlling
-jobs on the Jenkins programatically. Even though Jenkins provides an awesome UI for controlling
-jobs, it would be nice and helpful to have a programmable interface so we can dynamically and
-automatically manage jobs and other artifacts.
+This project is a simple API client for interacting with Jenkins Continuous
+Integration server. Jenkins provides three kinds of remote access API.
+1. XML API, 2. JSON API, and 3. Python API. This project aims at consuming the
+JSON API and provides some useful functions for controlling jobs on the Jenkins
+programatically. Even though Jenkins provides an awesome UI for controlling
+jobs, it would be nice and helpful to have a programmable interface so we can
+dynamically and automatically manage jobs and other artifacts.
 
 DETAILS:
 --------
-This projects currently only provides functionality for the <tt>jobs, node, and system</tt> interfaces.
-This is still a work-in-progress project. I mainly use the functionality of this project for my autmation
-work and the functionality mainly focussed on my usage and I believe others might find it useful
-too. I would love to add more features to it and I will continue working on improving existing
-features and add more interfaces such as nodes, views, build queue, etc,.
+This projects currently only provides functionality for the
+<tt>jobs, node, view, system, and build queue</tt> interfaces.
 
 USAGE:
 ------
@@ -44,33 +42,37 @@ Include this gem in your code as a require statement.
 
 ### Using with IRB
 
-If you want to just play with it and not actually want to write a script, you can just use the
-irb launcher script which is available in <tt>scripts/login_with_irb.rb</tt>. But make sure that
-you have your credentials available in the correct location. By default the script assumes that
-you have your credentials file in <tt>~/.jenkins_api_client/login.yml</tt>. If you don't prefer this
-location and would like to use a different location, just modify that script to point to the
-location where the credentials file exists.
+If you want to just play with it and not actually want to write a script, you
+can just use the irb launcher script which is available in
+<tt>scripts/login_with_irb.rb</tt>. But make sure that you have your credentials
+available in the correct location. By default the script assumes that you have
+your credentials file in <tt>~/.jenkins_api_client/login.yml</tt>. If you don't
+prefer this location and would like to use a different location, just modify
+that script to point to the location where the credentials file exists.
 
     ruby scripts/login_with_irb.rb
 
-You will see the that it entered IRB session and you can play with the API client with the
-<tt>@client</tt> object that it has returned.
+You will see the that it entered IRB session and you can play with the API
+client with the <tt>@client</tt> object that it has returned.
 
 ### Authentication
 
-Supplying credentials to the client is optional, as not all Jenkins instances require authentication.
-This project supports two types of password-based authentication. You can just you the plain
-password by using <tt>password</tt> parameter. If you don't prefer leaving plain passwords in the
-credentials file, you can encode your password in base64 format and use <tt>password_base64</tt>
-parameter to specify the password either in the arguments or in the credentials file.
-To use the client without credentials, just leave out the <tt>username</tt> and <tt>password</tt> parameters. The
-<tt>password</tt> parameter is only required if <tt>username</tt> is specified.
+Supplying credentials to the client is optional, as not all Jenkins instances
+require authentication. This project supports two types of password-based
+authentication. You can just you the plain password by using <tt>password</tt>
+parameter. If you don't prefer leaving plain passwords in the credentials file,
+you can encode your password in base64 format and use <tt>password_base64</tt>
+parameter to specify the password either in the arguments or in the credentials
+file. To use the client without credentials, just leave out the
+<tt>username</tt> and <tt>password</tt> parameters. The <tt>password</tt>
+parameter is only required if <tt>username</tt> is specified.
 
 ### Basic Usage
 
-As discussed earlier, you can either specify all the credentials and server information as
-parameters to the Client or have a credentials file and just parse the yaml file and pass it in.
-The following call just passes the information as parameters
+As discussed earlier, you can either specify all the credentials and server
+information as parameters to the Client or have a credentials file and just
+parse the yaml file and pass it in. The following call just passes the
+information as parameters
 
 ```ruby
 @client = JenkinsApi::Client.new(:server_ip => '0.0.0.0',
@@ -79,8 +81,8 @@ The following call just passes the information as parameters
 puts @client.job.list("^Testjob")
 ```
 
-The following example passes the YAML file contents. An example yaml file is located in
-<tt>config/login.yml.example</tt>.
+The following example passes the YAML file contents. An example yaml file is
+located in <tt>config/login.yml.example</tt>.
 
 ```ruby
 @client = JenkinsApi::Client.new(YAML.Load_file(File.expand_path(
@@ -91,8 +93,8 @@ puts @client.job.list_all
 
 ### Chaining and Building Jobs
 
-Sometimes we want certain jobs to be added as downstream projects and run them sequencially.
-The following example will explain how this could be done.
+Sometimes we want certain jobs to be added as downstream projects and run them
+sequencially. The following example will explain how this could be done.
 
 ```ruby
 require 'jenkins_api_client'
@@ -120,28 +122,35 @@ code = @client.job.build(initial_jobs[0])
 raise "Could not build the job specified" unless code == 302
 ```
 
-In the above example, you might have noticed that the chain method returns an array instead of a
-single job. There is a reason behind it. In simple chain, such as the one in the example above, all
-jobs specified are chained one by one. But in some cases they might not be dependent on the previous
-jobs and we might want to run some jobs parallelly. We just have to specify that as a parameter.
-
-For example: <tt>parallel = 3</tt> in the parameter list to the <tt>chain</tt> method will take the first three
-jobs and chain them with the next three jobs and so forth till it reaches the end of the list.
-
-There is another filter option you can specify for the method to take only jobs that are in a
-particular state. In case if we want to build only jobs that are failed or unstable, we can achieve
-that by passing in the states in the third parameter. In the example above, we wanted build all jobs.
-If we just want to build failed and unstable jobs, just pass <tt>["failure", "unstable"]</tt>. Also if you
-pass in an empty array, it will assume that you want to consider all jobs and no filtering will be
-performed.
-
-There is another parameter called <tt>threshold</tt> you can specify for the chaining and this is used
-to decide whether to move forward with the next job in the chain or not. A <tt>success</tt> will move to
-the next job only if the current build succeeds, <tt>failure</tt> will move to the next job even if the build
-fails, and <tt>unstable</tt> will move to the job even if the build is unstable.
-
-The following call to the <tt>chain</tt> method will consider only failed and unstable jobs, chain then
-with 'failure' as the threshold, and also chain three jobs in parallel.
+In the above example, you might have noticed that the chain method returns an
+array instead of a single job. There is a reason behind it. In simple chain,
+such as the one in the example above, all jobs specified are chained one by
+one. But in some cases they might not be dependent on the previous jobs and we
+might want to run some jobs parallelly. We just have to specify that as a
+parameter.
+
+For example: <tt>parallel = 3</tt> in the parameter list to the <tt>chain</tt>
+method will take the first three jobs and chain them with the next three jobs
+and so forth till it reaches the end of the list.
+
+There is another filter option you can specify for the method to take only
+jobs that are in a particular state. In case if we want to build only jobs
+that are failed or unstable, we can achieve that by passing in the states in
+the third parameter. In the example above, we wanted build all jobs. If we just
+want to build failed and unstable jobs, just pass
+<tt>["failure", "unstable"]</tt>. Also if you pass in an empty array, it will
+assume that you want to consider all jobs and no filtering will be performed.
+
+There is another parameter called <tt>threshold</tt> you can specify for the
+chaining and this is used to decide whether to move forward with the next job
+in the chain or not. A <tt>success</tt> will move to the next job only if the
+current build succeeds, <tt>failure</tt> will move to the next job even if the
+build fails, and <tt>unstable</tt> will move to the job even if the build is
+unstable.
+
+The following call to the <tt>chain</tt> method will consider only failed and
+unstable jobs, chain then with 'failure' as the threshold, and also chain three
+jobs in parallel.
 
 ```ruby
 initial_jobs = @client.job.chain(jobs, 'failure', ["failure", "unstable"], 3)
@@ -155,17 +164,34 @@ end
 ### Running Jenkins CLI
 To running [Jenkins CLI](https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+CLI)
 
+* authentication with username/password (deprecated)
+
 ```ruby
-@client = JenkinsApi::Client.new(:server_ip => '0.0.0.0',
+@client = JenkinsApi::Client.new(:server_ip => '127.0.0.1',
          :username => 'somename', :password => 'secret password')
 # The following call will return the version of Jenkins instance
 puts @client.exec_cli("version")
 ```
 
-Before you run the CLI, please make sure the following requirements are fulfilled:
-* JRE/JDK 6 (or above) is installed, and 'java' is on the $PATH environment variable
-* The ```jenkins_api_client/java_deps/jenkins-cli.jar``` is required as the client to run the CLI. You can retrieve the available commands via accessing the URL: ```http://<server>:<port>/cli```
-* (Optional) required if you run the Groovy Script through CLI, make sure the *user* have the privilige to run script
+* authentication with public/private key file
+remember to upload the public key to http://#{server_ip}:#{server_port}/user/#{my_username}/configure
+
+```ruby
+@client = JenkinsApi::Client.new(:server_ip => '127.0.0.1',
+         :identity_file => '~/.ssh/id_rsa')
+# The following call will return the version of Jenkins instance
+puts @client.exec_cli("version")
+```
+
+Before you run the CLI, please make sure the following requirements are
+fulfilled:
+* JRE/JDK 6 (or above) is installed, and 'java' is on the $PATH environment
+  variable
+* The ```jenkins_api_client/java_deps/jenkins-cli.jar``` is required as the
+  client to run the CLI. You can retrieve the available commands via accessing
+  the URL: ```http://<server>:<port>/cli```
+* (Optional) required if you run the Groovy Script through CLI, make sure
+  the *user* have the privilige to run script
 
 ### Using with command line
 Command line interface is supported only from version 0.2.0.
@@ -174,12 +200,46 @@ See help using <tt>jenkinscli help</tt>
 There are three ways for authentication using command line interface
 1. Passing all credentials and server information using command line parameters
 2. Passing the credentials file as the command line parameter
-3. Having the credentials file in the default location <tt>HOME/.jenkins_api_client/login.yml</tt>
+3. Having the credentials file in the default location
+   <tt>HOME/.jenkins_api_client/login.yml</tt>
 
 ### Debug
 
-The call to client initialization accepts a debug parameter. If it is set to <tt>true</tt> it will print
-some debug information to the console. By default it is set to false.
+As of v0.13.0, this debug parameter is removed. Use the logger instead. See the
+next section for more information about this option.
+
+### Logger
+
+As of v0.13.0, support for logger is introduced. Since it would be nice to have
+the activities of the jenkins_api_client in a log file, this feature is
+implemented using the Ruby's standard Logger class. For using this feature,
+there are two new input arguments used during the initialization of Client.
+
+1. `:log_location` - This argument specifies the location for the log file. A
+   good location for linux based systems would be
+   '/var/log/jenkins_api_client.log'. The default for this values is STDOUT.
+   This will print the log messages on the console itself.
+2. `:log_level` - This argument specifies the level of messages to be logged.
+   It should be one of Logger::DEBUG (0), Logger::INFO (1), Logger::WARN (2),
+   Logger::ERROR (3), Logger::FATAL (4). It can be specified either using the
+   constants available in the Logger class or using these integers provided
+   here. The default for this argument is Logger::INFO (1)
+
+If you want customization on the functionality Logger provides such as leave n
+old log files, open the log file in append mode, create your own logger and
+then set that in the client.
+
+#### Examples
+
+```ruby
+  @client = JenkinsApi::Client.new(...)
+  # Create a logger which ages logfile once it reaches a certain size. Leave 10
+  # “old log files” and each file is about 1,024,000 bytes.
+  @client.logger = Logger.new('foo.log', 10, 1024000)
+```
+Please refer to [Ruby
+Logger](http://www.ruby-doc.org/stdlib-1.9.3/libdoc/logger/rdoc/Logger.html)
+for more information.
 
 CONTRIBUTING:
 -------------
@@ -198,6 +258,6 @@ Please take a look at the issues page if you want to get started.
 FEATURE REQUEST:
 ----------------
 
-If you use this gem for your project and you think it would be nice to have a particular feature
-that is presently not implemented, I would love to hear that and consider working on it.
-Just open an issue in Github as a feature request.
+If you use this gem for your project and you think it would be nice to have a
+particular feature that is presently not implemented, I would love to hear that
+and consider working on it. Just open an issue in Github as a feature request.

data/Vagrantfile

@@ -0,0 +1,85 @@
+# -*- mode: ruby -*-
+# vi: set ft=ruby :
+
+Vagrant.configure("2") do |config|
+  # All Vagrant configuration is done here. The most common configuration
+  # options are documented and commented below. For a complete reference,
+  # please see the online documentation at vagrantup.com.
+
+  config.vm.hostname = "jenkins-api-client"
+
+  # Every Vagrant virtual environment requires a box to build off of.
+  config.vm.box = "Ubuntu-12.04-LTS"
+
+  # The url from where the 'config.vm.box' box will be fetched if it
+  # doesn't already exist on the user's system.
+  config.vm.box_url = "https://s3-us-west-2.amazonaws.com/squishy.vagrant-boxes/precise64_squishy_2013-02-09.box"
+
+  # Assign this VM to a host-only network IP, allowing you to access it
+  # via the IP. Host-only networks can talk to the host machine as well as
+  # any other machines on the same network, but cannot be accessed (through this
+  # network interface) by any external networks.
+  config.vm.network :private_network, ip: "33.33.33.10"
+
+  # Create a public network, which generally matched to bridged network.
+  # Bridged networks make the machine appear as another physical device on
+  # your network.
+
+  # config.vm.network :public_network
+
+  # Create a forwarded port mapping which allows access to a specific port
+  # within the machine from a port on the host machine. In the example below,
+  # accessing "localhost:8080" will access port 80 on the guest machine.
+
+  # Share an additional folder to the guest VM. The first argument is
+  # the path on the host to the actual folder. The second argument is
+  # the path on the guest to mount the folder. And the optional third
+  # argument is a set of non-required options.
+  # config.vm.synced_folder "../data", "/vagrant_data"
+
+  # Provider-specific configuration so you can fine-tune various
+  # backing providers for Vagrant. These expose provider-specific options.
+  # Example for VirtualBox:
+  #
+  # config.vm.provider :virtualbox do |vb|
+  #   # Don't boot with headless mode
+  #   vb.gui = true
+  #
+  #   # Use VBoxManage to customize the VM. For example to change memory:
+  #   vb.customize ["modifyvm", :id, "--memory", "1024"]
+  # end
+  #
+  # View the documentation for the provider you're using for more
+  # information on available options.
+
+  config.ssh.max_tries = 40
+  config.ssh.timeout   = 120
+
+  # The path to the Berksfile to use with Vagrant Berkshelf
+  # config.berkshelf.berksfile_path = "./Berksfile"
+
+  # Enabling the Berkshelf plugin. To enable this globally, add this configuration
+  # option to your ~/.vagrant.d/Vagrantfile file
+  #config.berkshelf.enabled = true
+
+  # An array of symbols representing groups of cookbook described in the Vagrantfile
+  # to exclusively install and copy to Vagrant's shelf.
+  # config.berkshelf.only = []
+
+  # An array of symbols representing groups of cookbook described in the Vagrantfile
+  # to skip installing and copying to Vagrant's shelf.
+  # config.berkshelf.except = []
+
+  config.vm.synced_folder ".", "/opt/jenkins_api_client"
+
+  config.vm.provision :shell, :inline =>
+    " sudo apt-get install -y git rubygems libxslt-dev libxml2-dev;" +
+    " cd /opt/jenkins_api_client;" +
+    " ls -lrt;" +
+    " ruby --version;" +
+    " sudo gem install bundler;" +
+    " bundle install;" +
+    " travis/setup.sh;" +
+    " bundle exec rake unit_tests;" +
+    " bundle exec rake func_tests"
+end

data/config/login.yml.example

@@ -21,3 +21,7 @@
 :username: my_username
 
 :password: my_password
+
+# The priviate key file for Jenkins CLI authentication
+# remember to upload the public key to http://#{server_ip}:#{server_port}/user/#{my_username}/configure
+:identity_file: ~/.ssh/id_rsa

data/jenkins_api_client.gemspec

@@ -4,16 +4,13 @@
 # -*- encoding: utf-8 -*-
 
 Gem::Specification.new do |s|
-  s.name = %q{jenkins_api_client}
-  s.version = "0.12.1"
+  s.name = "jenkins_api_client"
+  s.version = "0.13.0"
 
   s.required_rubygems_version = Gem::Requirement.new(">= 0") if s.respond_to? :required_rubygems_version=
   s.authors = ["Kannan Manickam"]
-  s.date = %q{2013-06-26}
-  s.default_executable = %q{jenkinscli}
-  s.description = %q{
-This is a simple and easy-to-use Jenkins Api client with features focused on
-automating Job configuration programaticaly and so forth}
+  s.date = "2013-07-10"
+  s.description = "\nThis is a simple and easy-to-use Jenkins Api client with features focused on\nautomating Job configuration programaticaly and so forth"
   s.email = ["arangamani.kannan@gmail.com"]
   s.executables = ["jenkinscli"]
   s.files = [
@@ -21,10 +18,12 @@ automating Job configuration programaticaly and so forth}
     ".jenkins.yml",
     ".travis.yml",
     "CHANGELOG.md",
+    "CONTRIBUTORS.md",
     "Gemfile",
     "LICENCE",
     "README.md",
     "Rakefile",
+    "Vagrantfile",
     "bin/jenkinscli",
     "config/login.yml.example",
     "java_deps/jenkins-cli.jar",
@@ -60,20 +59,21 @@ automating Job configuration programaticaly and so forth}
     "spec/unit_tests/system_spec.rb",
     "spec/unit_tests/view_spec.rb",
     "travis/jenkins_config.xml",
+    "travis/jenkins_config_with_crumb.xml",
     "travis/setup.sh",
+    "travis/setup_crumb.sh",
     "travis/spec.yml",
     "travis/user_config.xml"
   ]
-  s.homepage = %q{https://github.com/arangamani/jenkins_api_client}
+  s.homepage = "https://github.com/arangamani/jenkins_api_client"
   s.require_paths = ["lib"]
-  s.rubygems_version = %q{1.3.6}
-  s.summary = %q{Jenkins JSON API Client}
+  s.rubygems_version = "1.8.23"
+  s.summary = "Jenkins JSON API Client"
 
   if s.respond_to? :specification_version then
-    current_version = Gem::Specification::CURRENT_SPECIFICATION_VERSION
     s.specification_version = 3
 
-    if Gem::Version.new(Gem::RubyGemsVersion) >= Gem::Version.new('1.2.0') then
+    if Gem::Version.new(Gem::VERSION) >= Gem::Version.new('1.2.0') then
       s.add_runtime_dependency(%q<nokogiri>, ["~> 1.5.0"])
       s.add_runtime_dependency(%q<thor>, [">= 0.16.0"])
       s.add_runtime_dependency(%q<json>, [">= 0"])