Contents |
So you want to get a grasp on what's going on when you release? Enter REVS – Release Engineering Visibility System (a software previously know as grasp).
REVS...
It integrates with, but isn't part of the BOSS workflow system.
Implementation consists of :
The model is produced using the linux 'dia' tool and the master version can be found on gitorious.
The data model was written to support a vendor building a product on top of MeeGo.
It's not a purist model as it deals with the limitations of implementation choices.
SACK is the python/django component of REVS which has the sole purpose of providing the datamodel.
Package Group is a abstractish datamodel used by most of the REVS datamodels, most notably Platform, Product, Baseline and Product Release. This allows a list-like model of the data along with providing hierarchy (flat and recursive groups). The instances of Package Group consist of Package Links.
Package Group supports hierarchies of other Package Groups.
A Package Link represents things related to a package. It is used to allow grouping without replicating everything in the package. It has to have an underlying Package Name.
Package Links can derive to either pure Package, a Package Version, Installable (rpm) or Installable Version. See the later section for details about the each of the package classes.
A Platform is, at its basic form, a collection of packages. It represents a major distribution release and is used to group development releases, for example baselines.
The most basic example of a platform is MeeGo, which is a distribution.
Baseline represents a point in time snapshot of the Package Versions associated by the Packages in a Platform. A noteworthy point is that Platform does not "contain" baselines, it links to instances of baselines.
Product represents a collection of platforms that are used to run a distribution on a specific hardware. A subset of these packages usually form an iso or other device image.
An example of a product is MeeGo-N900, which targets N900 as its hardware and uses MeeGo as its distribution.
A ProductRelease is a collection of snapshots/Baselines of the Packages of relevant Platforms which make an image for a device. Inherits from PkgGroup to allow Releases to be collected.
Package Name is a separate entity from the Package Link. The primary purpose of it is to provide a linking between Package Name and Package Link (and its derivatives).
Package is the pure entity of a package, but represented with the functionality of a Package Link.
Installable represents the conceptual installable binary blob(s) that can be produced by a Package.
This represents the actual installable binary blob(s) produced by a given PackageVersion and found in an Image. Note that sometimes software is only provided as an InstallableVersion, eg. as a binary RPM.
NYC is another component of REVS, its purpose is to handle Licenses within releases, to identify any and all possible miscompatibilities.
License is a Package Group, thus it can have packages and sublicenses. An example is LGPL, which (in MeeGo) has packages scim and gamin and its sublicenses are LGPLv2 and LGPLv3 and LGPLv2.1.
REVS is currently available in gitorious:
http://meego.gitorious.org/meego-infrastructure-tools/revs
git clone git@gitorious.org:meego-infrastructure-tools/revs.git
Installable packages (deb/rpm) can be found here :
https://build.opensuse.org/package/show?package=revs&project=Maemo%3AMeeGo-Infra
Our release process involves creating a suitable branch such as : release-w50
This is then used to build images for staging; any bug fixes are applied to the release branch as well as master.
To create an OBS buildable package from a REVS git tree, you can either use a [[1]] or do it manually.
Manual steps are:
1. Check out the git sources
git clone http://git.gitorious.org/meego-infrastructure-tools/revs.git cd revs
1. Create a tarball out of the tree to a OSC checkout:
RELEASE=release-w50
VER=0.4
git archive --format=tar --prefix=revs-$VER/ $RELEASE | gzip > ${OSCCHECKOUT}/revs_$VER.tar.gz
cd ${OSCCHECKOUT}/
1. Commit the changes
osc commit
To use the above script, you can just issue:
./send_to_OBS.sh 0.4 ${OSCCHECKOUT}
Installing and setting up REVS is guided in the README file in the source code. It includes the following sections
When installing REVS via RPM, ther are specific instructions for it. For the rest of the chapters, the installation OS is assumed OpenSUSE, version 11.2.
When installing on openSuse, the following extra repos are needed :
zypper ar http://download.opensuse.org/repositories/server:/http/openSUSE_11.2/server:http.repo zypper ar http://download.opensuse.org/repositories/devel:/languages:/python/openSUSE_11.2/devel:languages:python.repo
Start up by pulling in the REVS repository information and refresh the repositories:
zypper ar http://download.opensuse.org/repositories/Maemo:/MeeGo-Infra/openSUSE_11.2-plus/Maemo:MeeGo-Infra.repo zypper ref
Then install the revs package:
zypper in revs
Create a file /etc/lighttpd/vhosts.d/revs.conf, with contents
var.namebasedir = "/revs"
$HTTP["url"] =~ "^" + namebasedir {
dir-listing.activate = "disable"
}
alias.url += (
namebasedir + "/static" => "/usr/share/revs/static/",
namebasedir + "/media" => "/usr/lib/python2.6/site-packages/django/contrib/admin/media/",
)
url.redirect += (
"^" + namebasedir + "$" => namebasedir + "/"
)
fastcgi.server += (
"/revs.fcgi" => (
"main" => (
"socket" => "/var/run" + namebasedir + ".socket",
"check-local" => "disable",
)
),
)
url.rewrite-if-not-file += (
"^(" + namebasedir + "/.*)$" => "/revs.fcgi/$1"
)
And uncomment the following line in /etc/lighttpd/lighttpd.conf:
include_shell "cat /etc/lighttpd/vhosts.d/*.conf"
Also make sure that modules alias, redirect, rewrite and fastcgi are enabled.
If you did a fresh install of the MySQL database, see the following section. Otherwise skip to database creation.
Mysql database is needed by revs, but the setup is not too hard.
Issue the following commands:
rcmysql start mysql_secure_installation
And answer the questions asked by the installation script. Move on to the next section.
REVS needs a functional mysql installation in order to work properly. The following script will do just that.
mysql -u root -p DROP DATABASE IF EXISTS revs; CREATE DATABASE revs CHARACTER SET utf8; CREATE USER 'revs'@'localhost' IDENTIFIED BY 'revs'; GRANT ALL ON revs.* TO 'revs'@'localhost'; FLUSH PRIVILEGES;
Afterwards issue the following commands:
django-admin.py syncdb --settings=revs.settings django-admin.py migrate --settings=revs.settings
If you want to create a superuser for Django, you may do so in the previous script.
REVS can be started up with its own initscript. Before running it, make sure you have completed each of the above section completely.
/etc/init.d/lighttpd restart /etc/init.d/revs start
To automatically start REVS on boot do:
chkconfig --add mysql lighttpd revs
After this, you can continue to importing data
REVS allows usage of Django test framework to run unit tests on its components. Example is provided by running
run_tests.sh
in the source root directory. It reports if all tests passed.
REVS has an API for controlling the models via HTTP. Currently Baseline, Package, Platform, Product, Product Release and Tracker models are modifiable and readable using our RESTful API.
Our REST implementation of choice is Django Piston, as it allows direct model handling using the Django ORM.
Currently the best way to use the API is using curl or anything that can GET / POST JSON. In curl this is achieved using
-d @file.json
as the command line parameter to get data from a file. See the API section for details and examples for each model.
Also the responses are given in JSON, so one might need eg. edit-json to view or edit JSON files.
The API handlers all support either pure url-encoded data or JSON. Each model is capable of both but this document reviews only the JSON input and output.
The following URLS are supported:
http://revs.host/revs/api/Package/<name> (Get a package name, list all versions) (Read/Write) http://revs.host/revs/api/Package/<name>/<version> (fetches a Package by Version) (Read-only) http://revs.host/revs/api/Product/ (shows a list of products) (Read-only) http://revs.host/revs/api/Product/<name> (shows specific product) (Read/Write) http://revs.host/revs/api/Baseline/ (shows a list of baselines) (Read-only) http://revs.host/revs/api/Baseline/<name> (shows specific baseline) (Read/Write) http://revs.host/revs/api/ProductRelease/ (shows a list of product releases) (Read-only) http://revs.host/revs/api/ProductRelease/<name> (specific product release) (Read/Write) http://revs.host/revs/api/Tracker/ (shows a list of trackers) (Read-only) http://revs.host/revs/api/Tracker/<name> (specific tracker) (Read/Write)
Also there are a couple of functional urls:
http://revs.host/revs/api/Package/<query>/search http://revs.host/revs/api/ProductRelease/<query>/search
JSON format for input and output
{
"platform": {
"name": "MeeGo"
},
"name": "1.1.80.2.20101019.1",
"date": "2010-12-12"
"pkgs": [
{
"version": "0.15",
"name": "spec-builder"
},
(many more packages)
}
JSON format for input and output
{
"name": "bluez",
"platform": "MeeGo",
"latest_version": "4.76",
"versions": [
{
"version": "4.70",
"package_system": "rpm",
"changelogentries": [
{
"date": "Thu Sep 30 2010",
"author": "Zhu Yanhai ",
"email": "<yanhai.zhu@linux.intel.com>",
"links": [],
"log": "- Add powered.patch to make sure the initial power status aligned\n with connman's requirement.\n"
},
{
"date": "Fri Aug 27 2010",
"author": "Zhu Yanhai ",
"email": "<yanhai.zhu@linux.intel.com>",
"links": [],
"log": "- Upgrade to 4.70\n"
}
]
},
... (many more versions)
}
JSON format for input and output
{
"name": "MeeGo"
}
JSON format for input and output
{
"platforms": [
{
"name": "MeeGo"
}
],
"name": "foobar",
"target_hardware": "n900"
}
JSON format for input and output
{
"release_of": "test",
"baselines": [
{
"name": "1.1.80.3.20101026.1"
},
{
"name": "1.1.80.2.20101019.1"
}
],
"name": "test_weekly_w45",
"date": "2010-17-12"
}
JSON format for input and output
{
"name": "MeeGoBugzilla",
"key2url": "http://bugs.meego.com/show_bug.cgi?id=%key%",
"url": "http://bugs.meego.com/",
"link_class": "Bug",
"filter2url": "<a ref=\"http://bugs.meego.com/show_bug.cgi?id=\\g<key>\">\\g<1></a>",
"regexp": "(\\BMC#(?P<key>\\ )\\))"
"platforms": [
{
"name": "MeeGo"
}
]
}
To parse changelogs directly from source rpms, use parse_release.py.
To feed parse release with .changes files, copy this script and run it against a MeeGo mirror directory to create tarballs of .changes files:
./get-M-changes.sh /mnt/obs_repository/repository/MeeGo/1.0.80/1.1.80.4.20101102.1/
#!/bin/bash
prjdir=$1
[ -d $prjdir ] || {
echo $prjdir is not a directory
exit 1
}
prj=$(basename $prjdir)
dir=$(dirname $prjdir)
mkdir $prj
cd $prj
get_changes() {
while read filename; do
rpmname=$(rpm -qp --qf %{NAME} $filename)
echo found $rpmname in $filename
rpm -qp --changelog $filename > $rpmname.changes
done
}
for area in core handset
do
find $prjdir/$area -name *src.rpm* | get_changes
done
cd ..
tar cjf $prj.tar.bz $prj
And then bunzip and tar -x the files, then run parse release for each baseline and platform, like this script does:
import() {
parse_release.py --force \
--platform=${platform} \
--baseline=${base} \
releases/${base}
}
platform=MeeGo
base=1.1.80.2.20101019.1
import
base=1.1.80.3.20101026.1
import
base=1.1.80.4.20101102.1
import
REVS supports Installables, which represent binary blobs, like binary rpms.
An Installable collection can be imported from PackageName objects in the REVS database, and Installables versions can be found using the underlying Package object of the PackageName. Versions are in the for of PackageVersion.
The script in GIT does exactly that.
The Installables are essential in creating Image objects in REVS, since Images are just a collection of binaries, which have a functionality to boot and provide the functionality of the binaries.
REVS is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 2 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this program. If not, see <http://www.gnu.org/licenses/>.