User Guide
- About this Guide
- I First Steps
- II Concepts
- III Setup
- IV Usage
- V Best Practices
- VI Reference
- 20 OBS Architecture
- 21 OBS Concepts
- 22 Build Process
- 23 Build Containers
- 24 Source Management
- 25 SCM Bridge [EXPERIMENTAL]
- 26 Supported Formats
- 27 Request And Review System
- 28 Image Templates
- 29 Multiple Build Description File Handling
- 30 Maintenance Support
- 31 Binary Package Tracking
- 32 Administration
- 33 Scheduling and Dispatching
- 34 Build Job Constraints
- 35 Building Preinstall Images
- 36 Authorization
- 37 Quality Assurance(QA) Hooks
- 38 openSUSE Factory
- Glossary
- A GNU Licenses
25 SCM Bridge [EXPERIMENTAL] #
25.1 SCM Bridge #
25.1.1 Introduction #
The SCM bridge allows to setup single packages or entire projects in any trusted SCM repositories. However, the only supported SCM is currently git.
This allows to manage the entire package sources in an external SCM repository. While the classic OBS services for scms (like obs_scm or tar_scm) are using the workflows inside of OBS, these workflows have to happen inside of the SCM provider instance. OBS will just verify the authenticity of that resource in future.
osc can be used to checkout sources. This will create a scm repository, so any modification needs to be done using the native scm tooling (eg. git). osc can still be used for local building and checking server side build results.
Be aware that any source mechanics like link or branch of OBS are not working when using the bridging. This means also that workflows are not working anymore or are limited. For example a submit request would still work when having scmsync on package level, but the user would manually specify the target always. It won't work at all when the entire project is managed via git. This briding mechanic is designed to follow the configured git provider, so this instance need to provide any required workflow.
25.1.2 Setup a package using the scm bridge #
The setup is purely done in package meta by defining the scm url inside of the scmsync tag:
<scmsync>https://gitlab.com/some/repository</scmsync>
The repository is cloned including all subdirectories, but the build descriptions need to be available on top level.
It is recommended just to reference further external build assets, like tar balls or git repositories using asset management. These assets will get downloaded and verified as well. Have a look in the pbuild documentation for further details on this.
25.1.3 Setup an entire project using the scm bridge #
An entire project can be setup by defining the scmsync tag in project meta data. Every top level subdirectory of the scm repository is considered as a package.
Large projects can use git submodules for each package. This avoids the need to clone the entire project for modifications on single packages.
The build configuration part can get stored as '_config' file in the top level directory.
25.1.4 Implementation and Limitations #
The sources are currently cloned for the OBS source server to allow OBS to process them. This is to be considered as an internal implementation detail and may change in future.
Git submodules: are cloned by default
Git VCS history: is not included for server side builds by default to save storage space. It can be included by adding a keepmeta=1 CGI parameter to the URL. This is not needed for local building when using osc.
Git LFS files: are not included by default. They can be included by adding a lfs=1 CGI parameter to the URL.
Using just a sub directory of the git repository can be done by adding a subdir=DIRECTORY CGI parameter to the URL.
Architecture specific remote assets can be selected by adding a arch=ARCH CGI parameter to the URL.
As example, this would like this for the subdirectory case:
<scmsync>https://gitlab.com/some/repository?subdir=MY_SUBDIRECTORY</scmsync>
25.1.4.1 Using a specific revision, tag or branch #
The url can define a revision, tag or branch via an url fragment. This means the url can get extended by a hash character and the revision, tag or branch.
<scmsync>https://gitlab.com/some/repository#MY_REVISION</scmsync>
This allows to setup multiple projects building for different branches. It is possible to use branches for implementing CI workflows. For example a submission test building just a subset, a clean build and a final reviewed build.
25.1.4.2 Converting to a project git #
A project git repository is mostly the same as any project for the pbuild tool. The
# osc create-pbuild-config
command is creating the _config file for a specific repository. This file is used by OBS as well as build configuration (aka prjconf). The additional _pbuild file is the pendant to the project meta and is not yet honored by OBS, but it can be part of the git tree anyway for pbuild users.
25.1.5 SCM Source Updates #
The OBS instance need to get notified on any change in the SCM server. This can be either achieved by single configurations for each git repository as documented in the Section 7.6, “Trigger a service run via a webhook” documentation. An alternative way is to configure it global. This requires admin permissions on the git hosting side and another bridge implementation. The advantage is that any used repository will be synced automatically just by referencing it via the scmsync meta tag.
This has been only implemented for gitea atm, you can find details in the obs-gitea-bridge documentation.