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

27 Supported Formats

Open Build Service is by design format agnostic, but it needs format specific support to be able to parse build descriptions and running the build. This chapter is focusing on describing Open Build Service specifics of a format. Either limitations or extensions of Open Build Service builds.

27.1 Spec File Specials (RPM)

To create an RPM package, you need a spec file.

  • A file with the extension .changes can be used to document the package history, but it is not required.

  • OBS-specific RPM macros which are set are: %_project and %_repository

  • #!ForceMultiVersion can be used to avoid resetting the build counter reset on version update. This is handled automatically in most cases. Explicitly adding this instruction is only needed when it is not possible to detect whether there are subpackages defining their own version. This can be the case when the subpackages are created dynamically via external rpm macros.

  • #!BcntSyncTag: STRING defines the build counter sync tag in a spec file. It is used when the bcntsynctag element tag is not defined in package meta. Also it can depend on architecture, repository or flavor for example.

  • #!BuildConflicts: STRING defines a conflicting package or dependency at build time only.

  • #!BuildIgnore: STRING ignores a dependency at build time.

  • #!BuildRequires: STRING Requires a build dependency. Usually the rpm native BuildRequires is the better way to define this. Use this tag only when the dependency should only exist when using the build script or OBS.

  • #!needsrootforbuild The build will be executed by root user. Please note that this must be permitted either by the OBS admin (via the BSConfig.pm configuration) or enabled in via build configuration rule. Also osc requires an additional parameter for local build (--userootforbuild).

  • #!needsslcertforbuild This will prepare an SSL certification based on the project key. It is used to create secure boot enabled packages usually. Please note that this will fail, if the project still has an old DSA key.

  • #!needsappxsslcertforbuild Creates an appx compatible ssl certificate based on the project key. Please note that this will fail, if the project still has an old DSA key.

  • #!needsbinariesforbuild All package files are usually removed before starting the build (after finishing to setup the build environment). This marker keeps them also during build.

27.2 OBS Extensions for (KIWI) Appliance Builds

KIWI appliance builds create images which can be used for direct consumption. Note: builds in non-VM environments do fail often due to the bootloader setup. Use osc build --vm-type=kvm for local building. OBS is evaluating kiwi builds at least two times. One time for the build host dependencies and another time for the target distribution used inside of the image. For container builds a third evaluation happens to find the base container.

KIWI builds inside of OBS need to fulfill following requirements:

  • config.xml files need to be renamed to a filename with .kiwi suffix.

  • repositories which are used must use either a URL which starts with the OBS download prefix or they must be written in obs://PROJECT/REPOSITORY syntax.

OBS extends kiwi functionality with following options. These covers cases which would need explicit command line commands, so they are covered via the tags to have them in a reproducible way.

  • A repository defined as obsrepositories:/ will used the expanded list of repositories as defined in the project meta. This is useful when moving kiwi image descriptions between projects, for example for development and release builds.

  • Defining build counter sync tag OBS-BcntSyncTag: STRING

  • An exclusive architecture list to build for can be defined with an xml comment OBS-ExclusiveArch: ARCH_LIST

  • An excluded architecture list to skip builds can be defined with an xml comment OBS-ExcludeArch: ARCH_LIST

  • A list of profiles to build can be defined via an xml comment OBS-Profiles: PROFILE_LIST

    This can also be handled via _multibuild flavor lists by setting a fixed string of OBS-Profiles: @BUILD_FLAVOR@

  • Packages get picked usually in a fixed order from the most important repository in OBS. This happens independently of the version number of the packages. Set the xml comment OBS-UnorderedRepos to disable the repository order handling and to have a more similar behavior as with plain package manager builds. Note: this can result into switching repositories between builds and is therefore less reproducible.

  • Container builds can specify a specific repository which shall be used for searching the base container. Use the XML comment OBS-Imagerepo:$REPOSITORY_URL for this. The repository URL may be in obs://$PROJECT/$REPOSITORY style.

  • Container builds can specify additional tags via OBS-AddTag:$TAG (KIWI limits it to one tag) in obs://$PROJECT/$REPOSITORY style.

  • A predefined milestone OBS-Milestone: milestone

    This defines a milestone name (for example, Beta1) which will be applied during release operations. The candidate will receive its final tag then.

27.3 OBS Extensions for Dockerfile based builds

OBS needs to parse RUN commands to detect build dependencies (repositories and packages). Currently calls from zypper, apt-get, yum and dnf are supported. Additional downloads need to be covered by source services. This ensures reproducible builds and a safe build environment without network access.

OBS extends Docker functionality with the below tags. Instead of these options, you would otherwise need explicit command-line commands. However, to make it possible to create reproducible builds, use the OBS tags.

  • A #!UseOBSRepositories tag will use the expanded list of repositories as defined via path elements in the project meta. This is useful when moving descriptions between projects, for example for development and release builds.

  • The tag #!UnorderedRepos will disable the repository prioritization for build dependencies. This behavior is similar to plain Docker tooling. It introduces the risk that with each build another repository is prioritized or that dependency problems of newer package versions are hidden.

  • #!BcntSyncTag: TAG to define the build counter sync tag.

  • #!BuildTag: TAG to define one or multiple tags to be used for the container.

  • #!BuildName: NAME Report back a defined NAME. Otherwise it gets derived from the first tag, replacing all / and : with - characters.

  • #!BuildVersion: VERSION Report back a defined VERSION. By default it is set to zero. The version is used by OBS for tracking. This needs to be set together with BuildName, otherwise it will be ignored.

  • #!ExclusiveArch: ARCH_LIST An exclusive architecture list to build for. The architecture list is separated by spaces.

  • #!ExcludeArch: ARCH_LIST An excluded architecture list to skip builds. The architecture list is separated by spaces.

  • #!ArchExclusiveLine: ARCH_LIST The next line will only be considered by the scheduler the listed architectures. The line will still get executed on all architectures during the build.

  • #!ArchExcludedLine: ARCH_LIST The next line will not be considered by the scheduler on the listed architectures. The line will still get executed on all architectures during the build.

  • #!Milestone: MILESTONE This defines a milestone name (for example, Beta1) which will be applied during release operations. The candidate will receive its final tag then.

  • #!NoSquash disables the squashing of all layers created during the build to a single layer. Without this, every RUN line is an additional layer.

The used filename of the build results are only important inside of OBS. The publishing happens via the built-in registry interface which is providing all defined tags for an image. The filename itself may be used on aggregates or other binary filters in OBS. It is either derived by the first defined tag or by the BuildName and BuildVersion tag if both are defined.

Print this page