Introduction

The savannah cli interface enables to see/change entries in the savannah tracking systems as well as submit new items or clone a copy of existing ones. It can be used for all savannah trackers independently of the project as long as you have a user account that allows you to perform these operations.

Other use cases for the CLI is to use Savannah as a state machine if you have an automatic workflow.

For the moment the tool has only been tried out on the gLite patch tracker and there might be issues for other trackers. Be careful when trying it out as the result will become immediately live!

Mailing List / Support

There is a low volume mailing list 'savannah-cli-users' which all users of the script are strongly urged to join. See https://groups.cern.ch/group/savannah-cli-users/default.aspx. It is used for announcements, feature requests etc. All bugs should be reported against the Savannah CLI category in the glite integration group on, yes, savannah.

How to install

The savannah cli uses some packages internally and is based on python. To use the CLI tool, you need to have python & python-devel (to install from the tarfiles below) installed on your machine and you need to install the internal packages.

Those packages are:

• twill-0.9.tar.gz
• PyXML-0.8.4.tar.gz
• BeautifulSoup.tar.gz
• ClientForm-0.2.9.tar.gz

Depending on your distribution, some of these packages may be available as binaries: ubuntu/debian users should

sudo apt-get install python-twill python-beautifulsoup python-clientform

The easiest way is to do the manual installation using the script install_deps.sh in the CVS which does everything automatically. It is not needed to be root to run this script.

An alternative way is to download the packages manually and after that, untar them, build each one of them and install the package. The procedure is as follows (As a root user):

•  tar xvfz downloaded_file.tar.gz 

•  cd  new_directory 

•  python setup.py build 

•  python setup.py install 

The script is still under development, see the #Development section for SVN (and legacy CVS) checkout details

Usage

Please be VERY CAREFUL with this tool: if items are wrongly updated, they will have to be fixed manually; the DB cannot be restored for a single project (backups are for dealing with hardware problems).

The tool presently supports the following operations

• Read a parameter of a given savannah item
• Set a parameter of a given savannah item
• Get available options for a listbox item of a given savannah item
• List all fields of a savannah item
• Clone an item Attention the priority is not conserved via this option as this is not part of the submit fields
• Submit an item
• Add a comment to a bug/patch

The options to be specified depend on the actual operation (see below)

Example of execution:

Clone an existing patch

Bulk update bugs to new status

• small no of bugs:

$ for b in 50000 50034 47245 ; do ./savannah -t bugs -o set -i $b -n Status -v Accepted -g jra1mdw ; done

• Large list of bugs in a file

$ while read b ; do ./savannah -t bugs -o set -i $b -n Status -v Accepted -g jra1mdw ; done < bug_list_inputfile

Submit a new item

To submit a new item you need to prepare an xml file with the corresponding information. The syntax is as follows:

<submit>
   <item1>xxx</item1>
   <item2>yyy</item2>
</submit>

where item1 is for example assigned_to.

An empty example file for the gLite patch tracker can be found here: glite-patch-submit-example.xml

Options

./savannah -h 

Script to interface to savannah tracking system

Savannah CLI v. Revision: 1.7

Usage:  savannah

    -h --help       Show this help
    -l --login      Allows the user to explicitly log in Savannah
    -V --verbose    Activate progress messages

  Mandatory parameter:
    -t  --tracker        Savannah tracker [patch,bugs]
    -o  --operate        Operations (see below for supported operations)

  Optional parameter (depending on operation):
    -i --item       Savannah item number
    -n --name       Savannah parameter name
    -v --value      New value/comment
    -g --group      Savannah group (for gLite this is jra1mdw)
    -f --file       file containing submit information in xml format

          Supported operations are:

                 Operation                                    | required options
                 ---------------------------------------------------------------
                 comment         Add a comment                | [i,v]
                 set             Set value                    | [i,n,v]
                 list            List available values        | [i]
                 get             Get a parameter              | [i,n]
                 get_available   Get available values         | [i,n]
                                 for selectbox
                 clone           clone (priority not cloned)  | [i,g]
                 submit          submit a new item            | [g,f]

Known issues

These issues might be treated in future versions:

• Full support of other groups besides glite (clone and submit are partly tracker specific)

'Group' specific information from savannah:

gLite (jra1mdw)

Available fields (patch tracker)

Decoding for select box fields for the gLite patch tracker

Development

http://svnweb.cern.ch/world/wsvn/aelwell/savannah_cli/

"take me to the source": Guest access:

svn co http://svnweb.cern.ch/guest/aelwell/savannah_cli/trunk

Revision History (From version 1.7)

New features in version 1.7:

 ./savannah -t patch -o comment -i XXXX -v "This is a new comment" 

New features in version 1.9:

Requirements to be added:

#	Bug #	Requirement	Description
1	58161	Attach bugs to a patch.	Example of use: /savannah -t patch -o attach -i patch_number -s "Integration Candidate" -c "Configuration" Where -s is the status of the bugs you want to move to the patch and -c is the category of the bugs you have to look for. These options would help you to query for the bugs.
2	58163	Change the status of patches for a certain PPS or prod release.	Example of use: /savannah -o release -t pps -r "3.1.0 PPS Update 40" Where -t tells you that it's a pps/prod release and therefore the state of the patches should be moved to "In Preproduction"/"In production" and you have to query using the information provided in the -r option, which in a Savannah patch is the Release field (for production) and Pre-production release field (for pps).
3	58165	Update status of all dependent bugs when a patch changes to 'In PPS'	For example, patch #2766 moved from Certified to In Production but the bugs are still in fix certified or ready for test
4	58166	Check correlation between patches and tasks	Check that all patches ready for certification also have a task associated with them. Will mean that the CLI needs to be able to work with 2 groups at once (jra1mdw[patches] and egee-sa3[tasks]) - iterate over patches 'ready for cert' or 'in cert' and check that there's at least one task associated with it

Recent Changelogs

• glite-patch-submit-example.xml: Example submit for gLite patch tracker