Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]

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 will happen now inside of the SCM provider instance. OBS will just verify the authenticity of that resource in future.

Any source processing by source services is not supported by design. All source management, review and merge handling needs to happen on the SCM side.

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 be used for local build tests and checking server side build results.

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 Extensions for GIT repositories

The following tweaks can be used for git repositories.

25.1.4.1 Using content from a subdirectory only

The scmsync url can get extended via a subdir query variable. Only the specified sub directory will be used in that case. For example

<scmsync>https://gitlab.com/some/repository?subdir=MY_SUBDIRECTORY</scmsync>

25.1.4.2 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.

Print this page