27 Supported Formats #

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.

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.

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.

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.