Some required tools for compiling and testing libstorage-ng are:
gcc-c++ boost-devel libjson-c-devel libxml2-devel libtool doxygen graphviz python3-devel python3-networkx ruby ruby-devel rubygem-test-unit swig >= 3.0.3 and != 3.0.8 (from YaST:storage-ng)
In addition to the previous packages, add these distribution-specific packages as well.
For some openSUSE/SUSE distributions the naming of
rubygem-test-unit might be the following:
make -f Makefile.repo make -j$(nproc)
Some files used to generate the bindings must be updated using tools in the utils directory.
When changing any exception specification (those in comments for
doxygen) you have to run
./generate-catches.py > ../bindings/storage-catches.i.
When changing the class hierarchy of classes derived from Device or
Holder you have to run
./generate-downcast.py > ../bindings/storage-downcast.i.
Make sure the documentation generated by doxygen is up-to-date before running the utils above.
Running Unit Tests
make -j$(nproc) install DESTDIR=/tmp/scratch make -j$(nproc) check LOCALEDIR=/tmp/scratch/usr/share/locale
Making an RPM
make -f Makefile.repo make package cd package osc build --local-package --alternative-project=openSUSE:Factory
Creating Changes And Package And Submitting To OBS
Creating the changes file and tar archive are handled by jenkins using linuxrc-devtools.
Additional files needed for OBS building are placed in the
You can generate a preview of the changes file by running
and create the tar.xz source archive by running
Package versions are tracked by setting version tags in git. The last version digit is auto-increased with every OBS commit.
VERSION file is auto-generated from the latest git tag.
The version can be set manually by setting the appropriate tag in git. As jenkins also sets version tags during the auto-submission process it is needed to turn off the jenkins job temporarily. So, to set the version to a specific number, follow these steps:
- disable the
libstorage-ng-masterproject on the internal jenkins node
- merge your latest changes
- set desired version tag - Don't forget to push tags!
- re-enable the
- trigger new build (or wait)
Remember, version tags should be
X.Y.Z for master and
BRANCH-X.Y.Z for other branches.
For a more detailed description about the handling of version numbers and changelog entries look here.
Jenkins will auto-submit only the
master branch. Other branches usually imply a maintenance update.
To trigger updates for these branches, go to the
project on our internal jenkins node. Choose
Build with Parameters and
select the desired target.
Versioning follows YaST's versioning scheme.
Currently this means
- 4.2.X for the
masterbranch submitted to
- 4.1.X for the
SLE-15-SP1branch submitted to
- 3.3.X for the
SLE-15-GAbranch submitted to
See especially the class hierarchy:
For continuous integration at GiHub the Travis CI service is used. To have the required build environment we use the yastdevel/libstorage-ng docker image. See the Travis documentation for more details.
Travis Cache Cleanup
The cache is maintained automatically and does not need any intervention. However, in a very rare case you might need to clear the cache and start from scratch.
- You can directly remove the cache archive at Travis, but this requires the appropriate access permissions.
- If you are not allowed to remove the cache at Travis then temporarily uncomment the cache cleanup code in the .travis.sh file. After the cache is cleared you can remove this temporary commit, Travis will use empty cache for the next build.