Client user manual

Installation

Log in to some machine (let it be lxplus). At the moment builder and server are provided together (with some part of client libraries). But there is separate package with standalone client (subdirectory slcb-client).

You can copy client scripts from AFS:

mkdir slcb
cd slcb
cp -r /afs/cern.ch/project/linux/dev/newbuildsys/slcb-client/ .

Or checkout them from CVS:

cvs checkout slcb/slcb-client
cd slcb/slcb-client

When checkouting from CVS, you need to copy certificates (or use your own):

cp /afs/cern.ch/project/linux/dev/newbuildsys/u0-?.pem .
cp /afs/cern.ch/project/linux/dev/newbuildsys/CA.pem .

You can modify [Server] section in client.conf file (provide address_* values) to connect to other running instances. Default values are now set for server running at lxdist-ia64.cern.ch machine.

address_upload = https://lxdist-ia64.cern.ch:30003
address_download = https://lxdist-ia64.cern.ch:30009

Now you can run your client with command (you will get available command list):

./client.py help

Client usage

Checking building rules:

There is one rules file per building target. Look into file targets/slc-4-core.csv on client machine . Example content:

# Some comment
kernel\w+,"target=i686,x86_64",%packager="Leszek Grzanka",%vendor="SLC",builder=mock
# This is comment : mc\w+,"target=i686,x86_64",%packager="Leszek Grzanka",%vendor="SLC",builder=mock,chroot=02
.+,%packager="Jaroslaw Polok <jaroslaw.polok@cern.ch>",%vendor="Scientific Linux , http://www.scientificlinux.org",builder=rpmbuild,parameters="-v"

In first column you have pattern for package name. Last row containing matching pattern is chosen to be option set. For example for package "filesystem-xyz" row with pattern "filesystem\w+", despite it match against patterns "\w+" and "grep\w+".

Next fields can be provided in random order, but they have to be in form "key=value" or "key=value1,value2,...". At this moment yo can specify following options:

• key: target , value: one or many of set {i386,x86_64,ia64} [mandatory,need to be quoted, if ',' used to separate fields]
• key: builder, value : on of {mock,rpmbuild} [mandatory]
• key: chroot, value: string - suffix of chroot path [optional, default=01]
• key: %packager, value: string [optional]
• key: %vendor, value: string [optional]
• key: parameters, value: string [optional, work only with builder=rpmbuild]

Checking builders status:

Run commands:

./client.py list_builders
./client.py update_builders

You will get following output:

Builders:
------------------------------------------------------------------------------------------
  https://lxdist-i386.cern.ch:30001                                             unavailable
  https://lxdist-amd64.cern.ch:30001      x86_64 amd64 ia32e noarch             alive    slc-3-x86_64-core slc-4-x86_64-core
  https://lxdist-ia64.cern.ch:30001                                             unavailable

Build Server accepting requests on lxdist-ia64.cern.ch:30007.

First column is builder address, second : supported architectures, third : status, fourth : build target strings

Submitting job:

Run command:

./client.py build my-job-name /afs/cern.ch/project/linux/cern/slc4X/SRPMS/file-4.10-2.src.rpm slc-4-core

This will submit job to all builders which supports target slc-4-core and architecture specified in target/slc-4-core.csv file. For specification build target - see Checking building rules

It is possible to give on what architecture(s) job should be build:

./client.py build my-job-name /afs/cern.ch/project/linux/cern/slc4X/SRPMS/file-4.10-2.src.rpm slc-4-core archs i686,ia64

Checking status of job:

Listing all jobs:

./client.py list

You will get list with rows in form: jobid: (srpm path) hostname status/result [ builder_hostname(architecture): unique_archjob_id status/result ]

Listing failed jobs (or failed, but with jobid greater than 30):

./client.py list status failed
./client.py list status failed uid_gt 30

List building jobs

./client.py list status building

List waiting jobs

./client.py list status waiting

List by result flag:

./client.py list result success

It is possible to combile list parameters.

Checking single job state (with jobid = 30):

./client.py detail 30

Fetching results:

If status of some job (eg. 30) is needsign/success (all archjobs are done/done), you can download resulting files to some directory (eg: /tmp/2):

./client.py fetch 30 /tmp/2

You can download resulting files of all successful jobs to some directory (eg: /tmp/2) with command:

./client.py fetchall result success dest /tmp/2

Logs will be overwritten, RPMs and SRPMs won't be.

-- LeszekGrzanka - 14 Aug 2007