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