Links

This is developer documentation about the different types of "links" that exist in the OBS

Interconnect Links

The OBS instance to OBS instance link. If a Project has the attribute remoteurl it acts as an read only interface to the OBS API behind this URL.

Example:

[1] pry(main)> Project.find_by(name: 'openSUSE.org').remoteurl
=> "https://api.opensuse.org/public"

The backend supports reading from such interconnects by using the sub-project syntax (project:sub-project). So in the example above openSUSE.org:home:hennevogel will fetch the data from project home:hennevogel on the remote OBS instance. Those "projects" are often called remote-projects.

Pitfalls

1. The support in the frontend for remote-projects is spotty. Some features, workflows etc. will simply not work for them. Most prominent: You can not view them in the UI.

2. If you try to instantiate a Project from an interconnect you will get a string and not an Project object... 🤯

[1] pry(main)> Project.get_by_name('home:Admin').class.name
=> "Project"
[2] pry(main)> Project.get_by_name('openSUSE.org:home:hennevogel').class.name
Found local project openSUSE.org for home:hennevogel with remoteurl https://api.opensuse.org/public
=> "String"

3. You can create sub-projects of interconnect links which will supersede the remote projects. This will turn those into "real" projects so you can have a mixture of local and remote projects below an interconnect-link.

[1] pry(main)> Project.get_by_name('openSUSE.org:home').class.name
=> "String"
[2] pry(main)> Project.get_by_name('openSUSE.org:home:hennevogel').class.name
=> "Project"
[3] pry(main)> Project.get_by_name('openSUSE.org:home:dmarcoux').class.name
=> "String"

4. Remote projects are also not checked for existence.

[1] pry(main)> Project.get_by_name('openSUSE.org:I:dont:exist')
Found local project openSUSE.org for I:dont:exist with remoteurl https://api.opensuse.org/public
=> "openSUSE.org:I:dont:exist"

Project Links

The OBS project to OBS project links. A project-link is a Project that has a LinkedProject associated. This association points to the project this Project gets its packages from.

Pitfalls

1. Instantiating a Package will follow project-links by default. That means that the Package object you get might have a different Project associated with it than the project name you used for instantiation... 🤯

[1] pry(main)> Package.get_by_project_and_name('openSUSE:Factory:Staging:O', 'aaa_base').project.name
=> "openSUSE:Factory:Rings:0-Bootstrap"

2. The LinkedProject association can point to an local Project object or to a String (see interconnect link)

3. If the LinkedProject association points to a remote-project then instantiating the package will return nil... 🤯

[1] pry(main)> Package.get_by_project_and_name('home:hennevogel:hans', 'ctris')
=> nil

4. You can have more than one project link. In this case the order in which packages are searched is defined by the attribute LinkedProject.position.

5. If you create a Package inside a Project it will supersede the Package from the project-link.

Package Links

The OBS package to OBS package link. A package link is a Package that has a PackageKind with the attribute kind: 'link' associated. This association is created as soon as the package has a file called _link in it's sources. Package links get their sources from the package they link to.

Pitfalls

1. There is no association between the two package objects.

2. The package it links to might not be an object on our instance (see interconnect link).

3. If Package has local files, they supersede files from the package-link. This is often called a "branch".

Mulitbuild Packages

The OBS Package.name to build description file name link. A Package can have a special file called _multibuild in its sources which turns it into a multibuild-package.

Pitfalls

1. Instantiating a Package with a multibuild flavor doesn't work.

[1] pry(main)> Package.get_by_project_and_name('OBS:Server:Unstable', 'obs-server:obs-api-testsuite-rspec')&.name
=> Package::Errors::UnknownObjectError: Package not found: OBS:Server:Unstable/obs-server:obs-api-testsuite-rspec

2. But you can pass an option to the instantiation method for this. So depending on how you instantiated the Package object in your feature/workflow/method it works for mulibuild-packages or not... 🤯

[1] pry(main)> Package.get_by_project_and_name('OBS:Server:Unstable', 'obs-server:obs-api-testsuite-rspec', {follow_multibuild: true})&.name
=> "obs-server"

3. Flavors are not validated for existence 🤯

Package.get_by_project_and_name('OBS:Server:Unstable', 'obs-server:thisflavordoesnotexist', {follow_multibuild: true}).name
=> "obs-server"

General Pitfalls

1. In general, combine any of the "links" above OR introduce a link cycle (link pointing to link that points back to the link) and it goes

2. Also as stated above, not every feature, class or method you will find will support all of the different link types.

Read the source Luke, good luck!