An optional distribution name can be included with the blueprint. If is
is not then the blueprint will be depsolved/built using the current host
distribution.
depsolveBlueprint and depsolveBlueprintForImageType check for the empty
Distro name and set it to the host distro before using it. The function
signatures have also been changed to use the value instead of a pointer
so that changes don't effect anything outside the depsolve function.
Explicitly set the kernel to boot into.
Also change the blueprint/kernenl handling:
Rather than only falling back to the default kernel name for
getting the package list, let GetKernel() always return the
correct result so we can rely on this being consistent.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Blueprints can now be used to specify a kernel as part of the kernel
customizations. Specifying a kernel adds it to the package list.
If no known kernel is specified (neither in the customizations nor the
package list), the default "kernel" is included automatically.
If kernels are specified in both the package list and the
customizations, both are added (even if they're duplicates).
According to the new guidelines in docs/errors.md.
Note that this does not include code that marshals to a writer that
might fail (when a connection drops, for example).
This makes two changes simultaneously, to avoid too much churn:
- move accessors from being on the blueprint struct to the
customizations struct, and
- pass the customizations struct rather than the whole blueprint
as argumnet to distro.Manifest().
@larskarlitski pointed out in a previous review that it feels
redundant to pass the whole blueprint as well as the list of
packages to the Manifest funciton. Indeed it is, so this
simplifies things a bit.
Signed-off-by: Tom Gundersen <teg@jklm.no>
If the user creates a new blueprint with no version specified, the
blueprint struct uses "0.0.0" as the default version. Blueprint tests
for a blueprint with an empty version now expect no error.
This changes it to an int pointer so that the JSON will output null.
This means it needs to be checked for nil or for 0 in go.
0 is not a valid revision in the WELDR response, they always start at 1
and increment for each new revision tag so either way is a valid way
to indicate it isn't set.
This changes osbuild-composer's behavior to match lorax-composer when
encountering invalid versions. Instead of leaving them as-is it will
return a BlueprintError explaining the problem. eg.
"errors": [
{
"id": "BlueprintsError",
"msg": "Invalid 'version', must use Semantic Versioning: is not in dotted-tri format"
}
]
This is enforced on new blueprints (including the workspace). If a
previously stored blueprint has an invalid version and a new one is
pushed it will use the new version number instead of trying to bump the
invalid one.
This also moves the version bump logic into blueprint instead of store,
and adds an Initialize function that will make sure that the blueprint
has sane default values for any missing fields.
This includes tests for the Initialize and BumpVersion functions.
The Blueprint struct is complex, deep, and full of references. This
means that any changes to it in memory will persist. Sometimes you need
an actual copy of it, so this adds DeepCopy which uses the json.Marshal
and Unmarshal functions to create a deep copy with no references to the
original.
This is not very efficient, but the alternative is adding Copy functions
to all the member structs and then calling them to build the copy.
When group names are passed on to dnf, they must be prefixed with an
ampersand, or they are treated as a regular package, potentially
causing the build to fail.
Add a testcase to verify this behavior.
This resolves rhbz#1784035.
Signed-off-by: Tom Gundersen <teg@jklm.no>
This takes a different approach to outputs and customizations, which is
much shorter and duplicates less code.
This uses links to internal repositories for now, because 8.2 hasn't
been released yet.
Add a `distro` flag to `osbuild-pipeline`.
This slightly changes the customizations logic. We now make sure
that each stage is appended exactly once.
customizations.go are now responsible only for the things that are
completely generic, and not per-ouput-type. helpers.go contain more
high-level helpers that combine customziations and per-output-type
defaults.
This does not change the behaviour, though some pipelines are slightly
reordered to make them consistent.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Add a struct to store changes made to a blueprint. Each change contains
a commit which is a hex string based off of an sha1 hash, a message
describing the change, a revision which will usually be null, a
timestamp, and the blueprint at the time of the change.
Introduce the `distro` package, which contains an interface for OS
implementations. Its main purpose is to convert a blueprint to a
distro-specific pipeline.
Also introduce the `distro/fedora30` package. It is the first
implementation of the distro interface. Most of its code has been copied
with minimal modifications from the blueprint package.
The `blueprint` package is now back to serving a single purpose:
representing a weldr blueprint. It does not depend on the `pipeline`
package anymore.
Change osbuild-composer and osbuild-pipeline to use the new API,
hard-coding "fedora-30". This looks a bit weird now, but is the same
behavior as before.
All test cases now also take an "distro" key in the "compose" object.
List of currently unsupported ones:
- [[repos.git]]
- [customizations.kernel]
- [[groups]]
- [[packages]] and [[modules]]
Some of customizations have unimplemented behaviour, see TODOs
Each output type will have its own translator from a blueprint to
a pipeline.
In the future, we may also want to distinguish between different
base distributions and architectures, but for now we keep it
simple and hardcode to a given one.
Some placeholder output formats are added, these have not been
tested or reserached, but are included to show how the it will
all fit together.
Signed-off-by: Tom Gundersen <teg@jklm.no>
This will contain all the translation logic from blueprints to pipelines,
which will constitute the main part of composer, so let's separate that
out from the API.
Signed-off-by: Tom Gundersen <teg@jklm.no>
