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

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

22.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 reseting the build counter reset on version update. s handled automatically in most cases. Just needed when it is not possible to detect r sub packages defining their own version. This can be the case when the sub packages eated dynamic via external rpm macros.

  • #!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.

22.2 OBS Extensions for (KIWI) Appliance Builds

KIWI appliance builds create images which can be used for direct consument. 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 fullfil 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.

  • 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 independend 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 behaviour 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.

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

  • #!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.

  • #!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.

Print this page