openSUSE:Build Service private instance software live cycle
Tagging project for copying projects from OBS to OBS
When delivering an project to a customer it might be interesting to be able to tag the project version that you want to deliver. Such tag will mark each package with revision marker at the time of its creation and will enable a later copy of that version. On OBS you can use two types of revision marker a sequence number and an MD5. As the revision marker is local to each OBS instance, the use of the MD5 is preferable when delivering a project. To ease that task I have created two scripts :
- obstag -> create a list of package with associated tag
- obs2obscopy -> copy using a tag as input.
Note When the tag is created on a remote OBS instance via the use of a local project which links on the remote public API, the tag will ONLY contain the packages name and the copy will be done using the current package revision.
Scripts can be found here openSUSE:OBS Light Obstag
Ignoring rpmlint warnings for a given package
rpmlint is a great tool, but if you import a package source which does not pass rpmlint checks and could not be bothered to fix it, you may just want to ignore it for the time being.
Deactivating rpmlint for a given package is easy.
- check out the package with osc
- get in the project directory
osc co myProject MyPackage cd "myProject:MyPackage"
- Create a file named MyPackage.rpmlintrc
- add in that new file a full blocking filter (that is a big extreme but will work)
# ignore all rpmlint output
addFilter(".*")
- add and commit
osc add MyPackage.rpmlintrc osc commit
Creating branches
Individual branches
OBS via the command line osc provides a solution to create branches in your own home project and later request integration of your changes via the collaboration model to the project owner.
Project branches
If you are going through the pain of creating your private OBS you will probably need to support some heavy projects. A common requirement is the creation of Project branches which are representing delivery to customers or partners in order to create a stable environment for the integration process or long term maintenance.
Creating a branch of a project is simply achieved by creating a new project on which you will copy all the packages. You have two methods at your disposition to make a copy available in your branched project.
- copy the source packages with the command osc copypac. If you use the option -e to expand the link, your branch will be completely detached from the source project. This non correlation can become a serious disadvantage if you need to back port features from the head at a later phase of the project.
- link toward fixed revision of the source packages into your branch by using the option -r or -c of the command osc linkpac. With this method your changes against the initial project can be introduced as patches, which makes the integration of potential future back ports much easier. Note that OBS will only automatically create patch files for changes done in simple files (e.g. configuration) but changes made to the source code of package will create a new .tar.gz. I strongly advise you to create patch files and register them in your spec file if you use links.
Tricks :
- After creation of the first Build Repo, your branch will be rebuilt from scratch, which could take a very long time if you have branched the packages containing the creation of the building tools (see Boot Strapping). You can short-circuit the system by creating your Build Repo against the source project used for creating the branch (all binaries are available and a boot strap is not required) and later, change the build repo to point towards itself (do not forget that second phase, or your branch will have an undefined status after the first first change in your source project).
- Links in your source project can quickly create serious difficulties in your branch. There is no general rule to deal with Links and how you should copy them into your branch. But you cannot afford to copy or link then silently. The following script will help you to identify them.
OSC="osc -A http://myobs-server.mycompany.com:444"
BRANCHES="MeeGo:1.0:branch_0513 MeeGo? :1.0:branch_0513:Restricted MeeGo? :1.0:branch_0729 MeeGo? :1.0:branch_0729:Restricted"
for BRANCH in $BRANCHES
do
echo "BRANCH: $BRANCH"
packages=$($OSC ls -u $BRANCH)
for package in $packages
do
files=$($OSC ls -u $BRANCH/$package)
if [ "$files" "_link" ] ; then
echo " PACKAGE: $package"
fi
done
done
Minimizing compiling time
If you are working on packages which are referenced by many other packages each modification will be cascaded by a series of useless package build which could very quickly overload your OBS instance. The kernel, build tools and drivers are part of this critical list.
If you work on these types of critical package, isolating them, during the development phase, in a branch which builds against your reference project will save you many hours, - maybe days - of compilation time.
Once your changes are tested and integrated in your branch, you can reintegrate your changes in the main project.
Building against a remote OBS repository
To build aginst an other instance of an OBS (e.g. building against MeeGo and OpenSUSE from your private OBS Instance) you have two main options
- creating a project link
- creating a Download Only project.
The advantage of the first method is that you build against a remote entity that you do not how to manage but if that remote entity is down your own OBS will be down The second method will download only the what you need to build from the remote OBS in your private OBS (copy of the :full directory). It does not give you access to the source, patches and config files. As the copy is done locally on your OBS you are not dependent on the availability of the remote OBS More on
Referencing multiple repositories
When you create a Build Repo it will, by default, point towards itself. This means that the packages listed in this project will expect to find all their building dependencies in that same project.
In general this will not be the case and you will point your repo to build against a project which represents a reference distribution. That selection can easily be made from the web UI.
But sometimes, and in particular when you are mixing proprietary code and open source code in a private OBS instance, you need packages from multiple repos.
The method for selecting multiple reference repos for a Build Repo is now available via the Web UI or via osc
It is often easier to use osc. You will find the method described here.
One of the side effect of using multiple repos in your build is the risk of conflict between packages of the same name but different release or different name but providing the same libraries. You can solve these conflict quite easily with the macro Prefer and Substitute in your OBS project prjconf.
For more details on these macros please look here
Integrating with Git
You can find a practical step by step GIT integration described here.
Tricks and known bugs
openSUSE OBS project maintains a list of Tips and Tricks which can be found here.