390c2afefa
This was debated as for SLE this would add some repetition when not going to match a SLE origin anyway, but it is necessary to stabilize maintenance origins. When an :Update project is first created all sources are inherited which means all the revisions from the top project's source container are considered. Once an update is provided via a maintenance incident the inherited sources are no longer presented and instead the only revision seen is the maintenance update and future updates. When a new version of Leap is created and all source containers are copied from the previous version the origin will first be considered :Update of the previous Leap version, but once a maintenance update is created it will drop the the non-:Update prior version since the matching revision is missing. If the update is submitted the origin will flip back to :Update. In order to avoid this mess always utilize include_project_link=True which will effective consider the maintenance update as the newest revision while continuing to consider the inherited revisions. For SLE, were all projects are stacked this means there will almost always be 10 revisions to review after the first could releases. Realistically this is yet another failing of the OBS source control model since the original source revision available (via inheritance) in the :Update project is lost after the first update.
openSUSE-release-tools
Everything denoted with a cloud is largely in this repository while the rest is the open-build-service (OBS).
Installation
For non-development usage just install the package.
zypper in openSUSE-release-tools
Many sub-packages are provided which can be found either by searching or looking on the build service.
zypper se openSUSE-release-tools osc-plugin
If CI builds are needed add the appropriate openSUSE:Tools repository.
Usage
All tools provide help documentation accessible via --help.
For osc plugins include the plugin name after osc like the following.
osc staging --help
For other tools execute the tool directly.
osrt-repo-checker --help
See the docs directory or a specific tool directory for specific tool documentation outside of --help. The wiki also contains some additional documentation.
Development
git clone https://github.com/openSUSE/openSUSE-release-tools.git
If working on an osc plugin create symlinks for the plugin and osclib in either ~/.osc-plugins or /usr/lib/osc-plugins. For example to install the staging plugin do the following.
ln -sr ./osc-staging.py ./osclib ~/.osc-plugins
It can also be useful to work against a development copy of osc either to utilize new features or to debug/fix functionality. To do so one must place the development copy in the path to be loaded and utilize the wrapper script if working on osc plugins. One method to accomplish this is shown below.
# outside of openSUSE-release-tools checkout
git clone git clone https://github.com/openSUSE/osc.git
# inside openSUSE-release-tools checkout
# note the ending /osc which points to the osc directory within the checkout
ln -s /path/to/osc/osc ./
# to utilize the wrapper for working on osc plugins from osrt checkout
$(realpath ./osc)/../osc-wrapper.py --version
A containerized OBS can be started via one command. The default credentials are Admin and opensuse on 0.0.0.0:3000.
./dist/ci/docker-compose-obs
An osc alias is automatically configured as local.
osc -A local api /about
A facsimile of openSUSE:Factory in the form of a subset of the related data can be quickly created in a local OBS instance using the obs_clone tool.
./obs_clone.py --debug --apiurl-target local
Some tests will attempt to run against the local OBS, but not all.
nosetests