Difference between revisions of "ABF Console Client"

From Rosalab Wiki
Jump to: navigation, search
(Added category)
Line 1: Line 1:
 
= Intro =
 
= Intro =
  
Our team (or just me) is about to start the development of the long-awaited project, console client for ABF!
 
  
Firstly we have to make up the list of features. All the demands and proposals are welcome in this mailing list (rosa-devel) or here.
 
  
 +
= Command List =
  
= Feature List =
+
==help==
   
+
If you want to get a help for some command - you've got two options: '''abf help <command>''' and '''abf <command> -h/--help'''  
=== abf get ===
+
'''[-h] [-b BRANCH] project'''
+
  
clone a project from ABF
+
==alias==
 +
Manage aliases for console client. With aliases you can make your frequently used commands shorter.
  
project: project name. ([group/]project). If no group specified, it's assumed to be your default group.
+
For example, you are going to work only with packages for rosa2012., you have to checkout to this branch after every "abf get" (or use -b rosa2012.1). But you can just add an alias like "g: get -b rosa2012.1" and after that "abf g" will do it automatically.
  
 +
Moreover, the alias name can be not only the first abf argument. For example, you can create another useful alias like "pack: rosa2012.1 build_branch -p" and run "abf copy pack" to copy contents of rosa2012.1 branch to build_branch and compress it.
  
'''-h, --help''': show this help message and exit
+
==== list ====
 +
List all the currently available aliases. By default this list looks like
 +
        b: build
 +
        sp: search projects
 +
        su: search users
 +
        st: status
 +
        s: store
 +
      spl: search platforms
 +
        sg: search groups
  
'''-b BRANCH, --branch BRANCH''': branch to checkout
+
==== add ====
 +
Add a new alias. the first argument is an alias name, all the arguments after that are alias target. For example, '''abf alias add sg search groups''' will срфтпу every call of "abf sg rosa" to "abf search groups rosa".
  
 +
==== remove ====
 +
Remove an alias. The only option is an alias name.
  
=== abf show ===
+
==get==
'''[-h] [-p PROJECT] type'''
+
Clone a remote git repository by its group and name. For example, '''abf get import/gcc''' will clone a project gcc from group import.
  
show some general information. Bash autocomplete uses it.
+
Options:
  
'''type''': {build-repos,build-platforms,save-to-repos,save-to-platforms} The type of information to show
+
'''-b <branch_name>''' specify a branch to check out inside a cloned git pepository.
  
'''project''': project name. ([group/]project). If no group specified, it's assumed to be your default group.
+
Notes:
  
 +
You can omit a group name, your default group (given from configs) will be used.
  
=== abf publish ===
+
==put==
'''[-h] task_ids [task_ids ...]'''
+
  
Publish the task that have already been built.
+
==store==
 +
==fetch==
 +
==show==
 +
==locate==
 +
==build==
 +
==mock-urpm==
 +
==rpmbuild==
 +
==publish==
 +
==copy==
 +
==status==
 +
==clean==
 +
==search==
 +
==test==
  
'''task_ids''': The IDs of tasks to publish.
 
 
 
=== abf build ===
 
'''[-h] [-p PROJECT] [-b BRANCH] [-t TAG] [-c COMMIT] [-s SAVE_TO_REPOSITORY] [-a ARCH] [-r REPOSITORY] [--auto-publish] [--update-type {security,bugfix,enhancement,recommended,newpackage}]'''
 
 
'''-h, --help''': show this help message and exit
 
 
'''-p PROJECT, --project PROJECT''': project name ([group/]project). If no group specified, it is assumed to be your default group. If the option is not specified and you are in a git repository directory - resolve a project name from it.
 
 
'''-b BRANCH, --branch BRANCH''': branch to build.
 
 
'''-t TAG, --tag TAG''': tag to build.
 
 
'''-c COMMIT, --commit COMMIT:''' commit sha hash to build.
 
 
'''-s SAVE_TO_REPOSITORY, --save-to-repository SAVE_TO_REPOSITORY''': repository to save results to ([platform/]repository). If no platform part specified, it is assumed to be "<default_group>_personal". If this option is not specified at all, "<default_group>_personal/main" will be used.
 
 
'''-a ARCH, --arch ARCH''':  architectures to build, can be set more than once. If not set - use all the available architectures.
 
 
'''-r REPOSITORY, --repository REPOSITORY repositories''': to build with ([platform/]repository). Can be set more than once. If no platform part specified, it is assumed to be your "<default_build platform>". If no repositories were specified at all, use the "main" repository from save-to platform. enable automatic publishing.
 
 
'''--update-type {security,bugfix,enhancement,recommended,newpackage}''': Update type. Default is "security".
 
 
'''NOTES:'''
 
 
API takes git commit hash to build. So client have to resolve it.
 
* If you've specified commit hash - it will be used "as is".
 
 
* If you've specified branch or tag name - it will be resolved automatically using ABF API. (the hash of top commit will be used for branch)
 
 
* If you've specified no git commit related options and you've specified a project name - this project's default branch will be used.
 
 
* If you've specified no git commit related options and you've not specified a project name (you have to be in a git repository) - the top remote commit of your current branch will be used.
 
 
 
 
=== abf buildstatus ===
 
'''[ID]'''
 
 
Get the status of the build task with ID.
 
 
'''ID''':  build list ID
 
 
 
=== abf backport SRC_BRANCH [DST_BRANCH] ===
 
'''[-h] [-p] src_branch [dst_branch]'''
 
 
Copy all the files from SRC_BRANCH to DST_BRANCH, or to the current brunch if not specified.
 
 
'''src_branch''':  source branch
 
 
'''dst_branch''':  destination branch. If not specified, it's assumed to be the current branch
 
 
 
=== abf put ===
 
 
'''[-h] message'''
 
 
Execute "git add --all", "git commit -m <your message>", "git push"
 
 
'''message''': a message to commit with
 
 
 
 
 
= Not Implemented Features =
 
 
=== abf localbuild ===
 
!! This is a draft of the funcionalities, please feel free to give your opinion !!
 
 
Build the project locally by using <mock> or <rpmbuild>
 
 
abf localbuild <type> [options]
 
 
- rpmbuild type options should mimic rpmbuild options, so a initial list should provide at least (copied from MDV bm):
 
 
  -a                    do everything and build source and binary packages
 
  -u                    just unpack
 
  -p                    unpack and run %prep stage
 
  -c                    unpack, run %prep, and compile
 
  -i                    unpack, run %prep, compile and install
 
  -s                    do everything and build source packages
 
  -b                    do everything and build binary packages
 
  -l                    show rpm output, besides copying to the log file
 
  -o OPT                pass given parameters directly to rpm
 
  --unpack-dir=DIR      specify directory where to unpack file(s)
 
  --build-log=FILE      specify where to put the build log for each package
 
  --sign                pass this option to rpm
 
  --nodeps              pass this option to rpm
 
  --debug              pass this option to rpm
 
  --short-circuit      pass this option to rpm
 
  --with                pass this option to rpm
 
  --without            pass this option to rpm
 
  --define              pass this option to rpm
 
  --target              pass this option to rpm
 
  --dryrun              do not commit changes to the system
 
 
Other bm options used for multiple project builds that *could* be available
 
  --move-srpm=DIR      move built srpm packages to given directory
 
  --move-rpm=DIR        move built rpm packages to given directory
 
  --move-failed-srpm=DIR
 
                        move original srpm packages to given directory, if
 
                        failed
 
  --copy-failed-srpm=DIR
 
                        copy original srpm packages to given directory, if
 
                        failed
 
  --remove-failed-srpm  remove original srpm packages, if failed
 
  --move-succeeded-srpm=DIR
 
                        move original srpm packages to given directory, if
 
                        succeeded
 
  --copy-succeeded-srpm=DIR
 
                        copy original srpm packages to given directory, if
 
                        succeeded
 
  --remove-succeeded-srpm
 
                        remove original srpm packages, if succeeded
 
  --move-log=DIR        move log files to given directory
 
  --move-failed-log=DIR
 
                        move log files to given directory, if failed
 
  --filter-renew=DIR    don't build packages if a newer version exists in
 
                        given directory
 
  --filter-refresh=DIR  only build packages if an older version exists in
 
                        given directory
 
  --clean              recursively remove directory used as topdir after the
 
                        build process
 
  --clean-on-success    same as --clean, but only remove if build has
 
                        succeeded
 
  --ignore=PKGNAME      ignore given package names (shell globbing allowed)
 
  --log=LEVEL          set logging level to LEVEL (debug, info, warning,
 
                        error)
 
 
- mock build options
 
???
 
 
=== abf rebuild ===
 
 
Execute the last executet ''abf build ...'' command for the project specified or to the current project if possible.
 
 
 
=== abf sync ===
 
 
Check and cleanup package sources and patches using current spec as base.
 
 
(delete all sources and patches from working directory if they are not listed in spec; inform if any listed patches/sources are missing; create proper file used to store tarballs on file server)
 
 
 
=== abf uploadsrpm ===
 
 
'''[GROUP] [-h] [-n NAME] [-d DESCRIPTION]'''
 
 
Create a new project in group GROUP or in your default group and upload the files from srpm file.
 
 
=== abf attach GROUP/PRJ PLAT_TARGET/REPO_TARGET [PLAT_ORIG/REPO_ORIG]===
 
=== abf detach GROUP/PRJ PLAT_TARGET/REPO_TARGET ===
 
 
Attach the project to the repository, or detach it from repository.   
 
 
Attaching with PLAT_ORIG/REPO_ORIG will detach project from one repo and attach to another.
 
 
 
   
 
For example, two commands:
 
 
'''abf attach import/mc rosa2012lts/contrib'''
 
'''abf attach import/mc rosa2012lts/main'''
 
 
equals:
 
 
'''abf move import/mc rosa2012lts/contrib rosa2012lts/main'''
 
  
 
[[Category:ABF Build Environment]]
 
[[Category:ABF Build Environment]]

Revision as of 16:51, 11 April 2013

Intro

Command List

help

If you want to get a help for some command - you've got two options: abf help <command> and abf <command> -h/--help

alias

Manage aliases for console client. With aliases you can make your frequently used commands shorter.

For example, you are going to work only with packages for rosa2012., you have to checkout to this branch after every "abf get" (or use -b rosa2012.1). But you can just add an alias like "g: get -b rosa2012.1" and after that "abf g" will do it automatically.

Moreover, the alias name can be not only the first abf argument. For example, you can create another useful alias like "pack: rosa2012.1 build_branch -p" and run "abf copy pack" to copy contents of rosa2012.1 branch to build_branch and compress it.

list

List all the currently available aliases. By default this list looks like

        b: build
       sp: search projects
       su: search users
       st: status
        s: store
      spl: search platforms
       sg: search groups

add

Add a new alias. the first argument is an alias name, all the arguments after that are alias target. For example, abf alias add sg search groups will срфтпу every call of "abf sg rosa" to "abf search groups rosa".

remove

Remove an alias. The only option is an alias name.

get

Clone a remote git repository by its group and name. For example, abf get import/gcc will clone a project gcc from group import.

Options:

-b <branch_name> specify a branch to check out inside a cloned git pepository.

Notes:

You can omit a group name, your default group (given from configs) will be used.

put

store

fetch

show

locate

build

mock-urpm

rpmbuild

publish

copy

status

clean

search

test