Never update the GitHub status at the end of a job. Instead, when
everything is done, the 'fail' job will run in the 'finish' stage and
update the status accordingly.
These tests are building just Fedora manifests, thus there's basically
no point in running them on RHEL, since we never support building
Fedora on RHEL.
This pipeline tests:
1. If the PR description is not empty (blocking)
2. If the PR title follows our format (non-blocking)
`component: This is the change (JIRA-001)`
3. If 1. and 2. are True, it adds a 'best practice' label to the PR
With the test the helper can now be slightly simplified. Because
we only have two results it seems easier to just use them directly
than to store them in an intermediate result struct.
The BLS specification [0] says the `options` field is optional and
can also appear multiple times. This commit tweaks the code to
deal with these corner cases and also adds tests that ensure that
this works correctly.
It also tweaks the file handling to be atomic.
[0] https://uapi-group.org/specifications/specs/boot_loader_specification/
When an images does not exist just return `False` instead of
raising a RuntimeError. If anything else goes wrong (unknown
output or hash mismatch) keep the RuntimeError as this is an
unexpected exception.
This commit tweaks the excellent work from Gianluca in PR#1550 a
little bit. Now that the container inputs are their own input
type some of the code that used to be part of the original
`inputs/org.osbuild.containers` can be simplified.
- Process all necessary operations related to CoreOS
platforms is crucial and specific to CoreOS. This step
is essential for CoreOS exclusively.
- Our approach to handling 'platforms.json' may change as we
advance with the OSBuild work. However, we don't have a clear
vision about how it will be in the future yet, particularly as
we also manage similar components within the osbuild composer
to configure cloud parameters. We probably will know better
when we start working with the cloud artifacts.
As a summary, let's add it know to unblock us, and if we find a
better approach in the future, we can always go back and remove it.
Signed-off-by: Renata Ravanelli <rravanel@redhat.com>
- Add functions for appending kernel parameters to the
Boot Loader Specification (BLS) as needed.
Signed-off-by: Renata Ravanelli <rravanel@redhat.com>
The source implementation used `subprocess.run()` argument
`capture_output`, which was added in Python 3.7. Since the minimum
supported Python version for osbuild on RHEL-8 is 3.6, the stage fails
with TypeError.
Example failure: https://artifacts.dev.testing-farm.io/c147b608-c40e-46ed-bf11-6b15ecf718dc/
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
The default overlayfs doesn't work inside the container runner which
causes the test to fail with
Invalid destination name
containers-storage:localhost/osbuild-skopeo-test-...:
'overlay' is not supported over overlayfs, a mount_program is
required: backing file system is unsupported for this graph driver
Changing the driver to vfs solves the issue.
A manifest (mpp and json) that uses the new source and input with the
skopeo stage.
This depends on the image we store at
./test/data/stages/skopeo/hello.img
The plan is to test this by pulling the hello.img into the host root
storage, build the manifest, delete the image from storage, and check
the tree.
When parsing a container input, add the checksum to the data as well.
Usually with other inputs, the stage only needs to know the filepath
where it can find the source content. In most (all, so far) cases, this
is a checksum appended to the content type.
In this case, the filepath is the location of the storage bind mount and
the checksum is needed to retrieve the container. The name might only
be a destination name (a name to use for storing the container in the
image), so we can't rely on it being valid in the source.
