The `/etc/rhsm/ca/redhat-uep.pem` CA is not valid for consumer
certificates.
As a result resolving the ostree ref should use the system's CA cert
pool.
If params.Ref is an empty string, it's set to the distro's default
ref. The only difference here is that the default ref also gets
verified.
It makes splitting out resolving ostree refs to a new job easier.
In the weldr and cloud apis, ostree.ResolveParams always got executed,
also for non-ostree image types. Make it more explicit by only resolving
if the image type is actually an ostree image.
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.
A new struct in ostree can be used to define configuration options for
the ostree remote of an image. So far remotes were always set up with
the remote URL used to pull the commit. Now we support setting a
different remote with extra configuration options.
This is used by the fedora-iot-raw-image to set up the remote
configuration of the final image, separately from the source of the
commit.
Test manifests updated.
Shorter and clearer error types.
- InvalidParameterError is now RefError. It is returned when a ref (the
new ref or the parent ref) is invalid.
- The ResolveRefError is not renamed. It is returned when a ref can't
be resolved (e.g., ref not found at URL).
New error type ParameterComboError. It is returned when a parent ref is
specified but no URL, which is an invalid parameter combination.
All parameters can now be specified at the same time.
See https://github.com/osbuild/osbuild-composer/issues/2131 for a
description of how the parameters are meant to interact.
In brief, the only invalid parameter combination is specifying a Parent
without a URL.
All other error conditions are for malformed URLs, invalid characters in
a ref, or error responses from the server.
Errors implement the error interface, so we can return them as generic
errors. Callers can test the type only if they want to determine the
failure type.
The error types that can be returned from each function are documented
in the docstring.
No need to pass the entire image type. We just need the default ref.
This removes the distro package dependency from the ostree package,
which we will need so distro can use the ostree types and functions.
Move OSTree option handling outside of the weldr API to make it usable
by other packages. New subpackage at internal/ostree.
Add support for ostree options ("Ref" and "URL") in the Cloud API.
Validate OSTree options and resolve the parent reference the same way as
in the Weldr API.
Unlike the Weldr API, the Cloud API doesn't support specifying the
Parent reference directly.
The exports list is included in the job information on the queue.
