Make the ostree commit spec mandatory in the OSTreeRawImage by adding it
to the constructor.
Use the ostree.CommitSpec to specify parameters in the OSTreeRawImage
ImageKind and the OSTreeDeployment Pipeline.
Make the ostree commit spec mandatory in the OSTreeInstaller ImageKind.
The installer image type is not just for ostree types so make the ostree
parameters optional for the ISOTree Pipeline.
Use the ostree.CommitSpec to specify commits parameters.
In the OS pipeline, the parent configuration was used to detect if the
pipeline's setup was meant for an ostree commit or not. Also, the
pipeline used a new type to specify the ostree parameters.
- Use the ostree.CommitSpec for the parent configuration.
- Add a new attribute, OSTreeRef, that defines the ref for the ostree
commit being built. An empty string indicates that the tree is not
for an ostree commit.
Additionally, in the ImageKind configurations for the ostree archive and
container, separate the ostree ref from the parent spec, make the parent
spec optional (pointer) and the ostree ref mandatory, by requiring it in
the constructor of the ImageKind.
Instead of using the ostree.RequestParams in the OSTReeImageOptions,
define a new struct specific to ImageOptions for the ostree parameters.
This is almost identical to the new ostree.CommitSpec but the meaning of
the parameters changes based on image type and it would not be clear if
the CommitSpec was used in all cases. For example, the parameters of
the new OSTreeImageOptions do not always refer to the same commit. The
URL and Checksum may point to a parent commit to be pulled in to base
the new commit on, while the Ref refers to the new commit that will be
built (which may have a different ref from the parent).
The ostree.ResolveParams() function now returns two strings, the
resolved ref, which is replaced by the defaultRef if it's not specified
in the request, and the resolved parent checksum if a URL is specified.
The URL does not need to be returned since it's always the same as the
one specified in the request.
The function has been rewritten to make the logic more clear.
The docstring for the function has been rewritten to cover all use cases
and error conditions.
The CommitSource was used to specify the source URL and checksum of a
commit for use in manifest sources. Renaming to CommitSpec and adding a
Ref parameter generalises the type so that we can use it to specify
commits in various situations. This is building towards separating when
ostree parameters are used for fetching a commit, fetching a parent
commit, and building one.
The CommitSpec is (very roughly) analogous to the rpmmd.PackageSpec.
osbuild 69 fixed a bug in the ostree.config stage that we now require
for setting the ior-raw-image [1].
The version hasn't been released yet, so pin osbuild version that
provides the fix for all distros.
[1] 8a7b6d382d
In order to run azure.sh inside CIV CI, we need to use the appropiate
tag. This means getting `prod` tag when running in osbuild-composer and
the pr tag when running in cloud-image-val
With an empty or missing version number the commit message would not
include the version (which is set to 0.0.0 by calling Initialize). This
adds a call to Initialize() in the API code before constructing the
commit message. It also moves the check for non-empty blueprint name
into the Initialize call where it belongs.
The connection can be briefly interrupted for short periods of time,
which is fine. To avoid spamming the logs with error messages, backoff
for half a second.
Currently errors like clienterror 28 ("at least one target failed") have
all the relevant information in the details, don't omit these details
from the worker logs.
This fixes a bug where tagging a blueprint would overwrite the blueprint
in the blueprintChanges storage with an older version of the blueprint.
It also adds checks to make sure the blueprint is present in the
blueprintsCommits and blueprintsChanges maps before trying to reference
them -- just in case something in the store gets out of sync.
TagBlueprint has a bug, it replaces the tagged blueprint with the last
untagged blueprint. The test wasn't testing for this, so correct that
before fixing the actual bug.
Don't pass blueprint Users and Groups options all the way down to the
osbuild stage bindings. Instead, convert them to the internal
users.User and users.Group structs.
Ideally we would do this even higher up in the code path, before
reaching the distro, but this is the first step towards that.
- Use newer granular stages to build the bootiso tree rather than the
deprecated bootiso.mono stage.
- Adjust the ISOTree struct properties: add the ones needed by the new
stages and remove any properties that have been moved to the new
pipelines.
