for these 2 scripts we make cleanup() defined in the outer scope and
make sure that it executes on EXIT rather than RETURN which makes it
possible to stick the journalctl killing functionality inside of the
same function.
Nightly pipelines test against older osbuild-composer versions so we
need to still modify the kickstart file until the feature reaches the
nightly composes.
Use the new installer customizations to build and boot an unattended
installation and add the users to the sudoers with NOPASSWD enabled.
This is added both to he base installer test (installers.sh) and the
ostree test (ostree-ng.sh). For the ostree test, we keep the mkksiso
step to retain the remote configuration change. The modksiso() function
is changed to explicitly read the osbuild.ks file since we don't want to
modify the osbuild-base.ks file and we want to ensure that the kernel
command line argument points to the osbuild.ks file.
test logs print:
[2023-08-22T10:18:14-04:00] 💿 Install image via installer(ISO) on VM
WARNING --os-type is deprecated and does nothing. Please stop using it.
We were using greenprint for failures, which makes it hard to quickly
find where the tests failed. This switches errors to use redprint, and
adds it to places that were simply using echo before doing an exit 1.
Since we're sharing functions between test scripts, move greenprint(),
the most rewritten function in the history of the project, to
shared_lib.sh and source it everywhere.
- Handle the array responses from the new weldr-client (>= 35.6).
- Move the `get_build_info` function to shared_libs.sh to source and
reuse in multiple places.
`tools/provision.sh` is provisioning SUT always in the same way for
both, the Service scenario and the on-premise scenario. While this is
not causing any issues, it does not realistically represent how we
expect osbuild-composer and worker to be used in these scenarios.
The script currently supports the following authentication options:
- `none`
- Intended for the on-premise scenario with Weldr API.
- NO certificates are generated.
- NO osbuild-composer configuration file is created.
- NO osbuild-worker configuration file is created. This means that no
cloud provider credentials are configured directly in the worker.
- Only the local worker is started and used.
- Only the Weldr API socker is started.
- Appropriate repository definitions are copied to
`/etc/osbuild-composer/repositories/`.
- `jwt`
- Intended for the Service scenario with Cloud API.
- Should be the only method supported in the Service scenario in the
future.
- Certificates are generated and copied to `/etc/osbuild-composer`.
- osbuild-composer configuration file is created and configured for
JWT authentication.
- osbuild-worker configuration file is created, configured for JWT
authentication and with appropriate cloud provider credentials.
- Local worker unit is masked. Only the remote worker is used (the
socket is started and one remote-worker instance is created).
- Only the Cloud API socket is started (Weldr API socket is stopped).
- NO repository definitions are copied to
`/etc/osbuild-composer/repositories/`.
- `tls`
- Intended for the Service scenario with Cloud API.
- Should eventually go away.
- Certificates are generated and copied to `/etc/osbuild-composer`.
- osbuild-composer configuration file is created and configured for
TLS client cert authentication.
- osbuild-worker configuration file is created, configured for TLS
authentication and with appropriate cloud provider credentials.
- Services and sockets are started as they used to be originally:
- Both local and remote worker sockets are started.
- Both Weldr and Cloud API sockets are started.
- Only the local worker unit will be started automatically.
- NO repository definitions are copied to
`/etc/osbuild-composer/repositories/`.
We want to be able to safely gather any artifacts without worrying about
any possible secrets leaking. Every artifacts that we want to upload
will now have to be placed in /tmp/artifacts which will then be uploaded
to S3 by the executor and link to the artifacts will be provided in the
logs. Only people with access to our AWS account can see them.
Most test scripts don't have any documentation regarding it's purpose,
although it can be guessed by the code. There's value in adding this
small comment.
[skip-ci]
With new weldr-client package the metadata tar archive created has
permissions set to 600 instead of 644 which causes permission failures
when interacting with it. Adding sudo to resolve that.
The commonly used 'greenprint' function now adds a date + timestamp to
each message for debugging and tracking the duration of segments of each
scripts.
Renamed tar-installer to image-installer.
This is a more appropriate name:
- It disassociates the image type from the "tar" image type. The two
should not be perceived to be connected.
- It's more descriptive. The format of the payload (tar) isn't relevant
to the purpose of the image type.
Several changes required to get the installer test working in CI.
Blueprint:
- Add packages for SSH and networking
- Use generated SSH key and username variable for user setup
Kickstart:
- The ISO contains a kickstart file with the `liveimg` command. Instead
of trying to inject a kickstart during virt-install, we override the
existing file on the ISO. The `modksiso` function reads a kickstart
file from an existing ISO, adds commands to make the installation
fully automatic (partitioning, text --non-interactive) and creates a
new ISO with the modified kickstart file using mkksiso.
- Simple networking added to kickstart file.
- Kernel command line args for installer added via the mkksiso command
since the `--cdrom` installation source doesn't support injecting
command line arguments.
virt-install:
- Using `--cdrom` instead of `--location`: latter was failing to
install.
- No longer injects a kickstart file (since we handle it separately) and
doesn't add extra Kernel args.
