particle-os/debian-forge
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
debian-forge/test/data
History
Tomas Hozza 5dc72038ef stages/chrony: extend chrony stage to allow additional directives 
The `org.osbuild.chrony` stage currently supports only a single option
'timeservers' which does not allow specifying additional options for the
configured timeservers. The option can not be easily extended to allow
specifying additional options and at the same time keep the backward
compatibility with old manifests.

The need for a lower-level stage option allowing to configure additional
options of the 'server' directive is required by RHEL AMI images, which
use 'maxpoll', 'minpoll' and 'prefered' options.

Extend the `org.osbuild.chrony` stage with two additional options. The
'servers' option accepts a list of dictionaries specifying timeservers
to be configured using the 'server' directive, including a subset of the
directive options. The 'servers' option can not be used at the same time
in the stage options as the 'timeservers' option.

The second added option is 'leapsectz' corresponding with a directive of
the same name. The value of the option is a string. If the provided
string is empty, then all occurrences of the 'leapsectz' directive are
removed from the `chrony.conf`. Otherwise, the 'leapsectz' directive is
added to the `chrony.conf` with the provided value, while all original
occurrences of the option are removed.

Add a new stage test case under `test/data/stages/chrony-servers` to
test the new variant of the stage options. The reason is that the
'timeservers' option conflicts with 'servers' option, which makes it
impossible to test both of them in the same test case.

Signed-off-by: Tomas Hozza <thozza@redhat.com>
2021-06-26 10:28:03 +01:00
..
manifests stages/cloud-init: add new stage for configuring cloud-init 2021-06-24 16:55:18 +02:00
os-release test: update test manifests to use Fedora 34 2021-06-07 12:15:26 +02:00
scripts test/data: add mount_flags.py helper script 2020-08-12 16:52:27 +02:00
sources test/sources: add checks for org.osbuild.inline 2021-05-12 14:26:16 +02:00
stages stages/chrony: extend chrony stage to allow additional directives 2021-06-26 10:28:03 +01:00
README.md test: rename mpp-*.json to *.mpp.json 2020-10-19 17:37:46 +01:00

README.md

OSBuild Test Data

This directory contains data used by the osbuild test-suite. Since many formats do not allow comments, this file shortly describes their purpose.

Directories

  • ./os-release/: This directory is consumed by the unit-tests of the os-release parser. The directory contains example os-release files (see os-release(5)). Their directory name is the expected output of the parser.

  • ./manifests/: This directory contains osbuild manifests used throughout the test-suite.

    Manifests prefixed with f30, f31, etc. are manifests that produce fedora images. If they have base as part of their name, they include a base set of packages which we very loosely define as @core plus the packages our test-suite needs. If they have build as part of their name, they have a very restricted package set which includes just what is needed in a build-root for osbuild. The fedora prefix is used for manifests that are kept up to date to the newest fedora release, and thus do not expose a specific f30, f32, etc. behavior.

    The rhel prefix is used for Red Hat Enterprise Linux images. Since they are not available publicly, the test-suite usually skips them.

    The filesystem manifest is used to test assemblers. These tests doesn't need a big filesystem tree representing a whole operating system. Instead, this manifest's tree is constructed just from the filesystem package and is marked using the selinux stage.

    Manifests ending on .mpp.json are fed through the ManifestPreProcessors and then stored in the same directory with an .json extension (replacing .mpp.json). generated files are committed to the repository. Nevertheless, if you need to regenerate them, use make test-data.

  • ./sources/: This directory contains test-data for runtime tests of the source-engines. It contains a directory that is served via HTTP in the tests, and a directory of test-cases what to expect when using the attached sources.json.

  • scripts: This directory contains scripts used from other tests, i.e. although they are executables they are at the same time test-data to the actual (unit) tests.