Use the autogenerated test framework from VSCode (with minor fixes to
make them compile).
As we do not yet support customizations in blueprint, all the tests are
trivial.
I was not entirely sure about the best way to encode the wanted pipeline
output. I currently represent it as a JSON string and unmarshal it into
the object to compare with.
Signed-off-by: Tom Gundersen <teg@jklm.no>
log.Fatalf not only writes into a log, but also exits the process.
Instead, we want the caller to handle the error.
Also, the logged message is imho wrong.
At the end of each set of tests the blueprint created is deleted.
This tests the delete route as well as removing blueprints
created while testing external apis such as lorax.
This was only used internally in the store package, so moved the
one type that was still used and remove the rest.
Signed-off-by: Tom Gundersen <teg@jklm.no>
This hides the state hanlding in the store package. As before, it
can be disabled by passing `nil` instead of the path to the state
file.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Wrap the channel in Pop and Push methods, so it is not exposed to
the callers. PushCompose replaces the old AddCompose for consistency,
and PopCompose simply reads from the other end of the channel.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Drop the jobUpdates channel, and instead add an UpdateCompose method
to the store, which updates the status of a compose directly.
This allows us to report back errors directly, rather than having to
mirror the staet in the jobqueue API.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Let the weldr API take the store as an argument, rather than create it
itself. This will allow us to share the store with the jobqueue API in
follow-up patches.
Signed-off-by: Tom Gundersen <teg@jklm.no>
This encapsulates all the state of osbuild, no longer just the state specific
to the weldr API. Make it a first class type, preparing for direct access from
both the weldr and jobqueue APIs.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Let the store in weldr be the only one that keeps state, and push
updates directly there. This fixes a bug where there was an ID mismatch.
Change the API to not let the caller pick the UUID, but provide it
in the response. Use the same UUID as is used to identify composes,
this makes it simpler to trace what is going on.
Signed-off-by: Tom Gundersen <teg@jklm.no>
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>
osbuild-composer's tests can be run against lorax-composer's api in
order to ensure parity with lorax. This can be accomplished by passing
the environment variable LORAX=true into the tests. Otherwise, the
tests run as usual against osbuild-composer's api.
This finishes the initial version of the pipline package, adding
documentation, but still missing unittests.
Signed-off-by: Tom Gundersen <teg@jklm.no>
osbuild-composer now uses socket activation instead of hardcoded paths
in the code. osbuild-worker is an http client therefore it uses only
service unit. osbuild-worker must be started after the socket is
created. osbuild-composer service requires osbuild-worker to run, because without
it no jobs can be started.
osbuild-composer is executed as a regular user (newly created
_osbuild-composer user) as opposed to the worker which must run as root
in order to execute osbuild itself
Use the exact same status strings as is used in the API,
making it clearer that they are the same (and avoiding any
translation). Remember the creation/start/finish timestamps.
And store the output type.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Go doesn't really do variants, so we must somehow emulate it. The
json objects we use are essentially tagged unions, with a `name`
field in reverse domain name notation identifying the type and a
type specific 'options' object.
In Go we represent this by having an BarOptions interface, which
implements a private method `isBarOptions()`, making sure that only
types in the same package are able to implement it. Each type FooBar
that should belong to the variant implements the interface, and a
constructor `NewFooBar(options *FooBarOptions) *Bar` that makes sure
the `name` field is set correctly.
This would be enough to represent our types and marshal them into
JSON, but unmarshalling would not work (json does not know about
our tags, so would not know what concrete types to demarshal to).
We therefore must also implement the Unmarshall interface for Bar,
to select the right types for the Options field.
We implement his logic for Target, Stage and Assembler. A handful
of concrete types are also implemented, matching what osbuild
supports.
Signed-off-by: Tom Gundersen <teg@jklm.no>
This way it can be correctly exposed in the API. We listen on a channel
from the job-queue, where status updates are pushed when the worker is
running/finished (or, in the future, failed).
Signed-off-by: Tom Gundersen <teg@jklm.no>
This means they are serialised and restarted in case composer is
crashed/restarted. We also need this in the future to track their
state, and allow them to be listed in the UI.
Signed-off-by: Tom Gundersen <teg@jklm.no>
For now we will hardcode the org.osbuild.local target, so we might
as well fix this up front.
We do not yet support any target types, but for testing purposes we
claim to support 'tar', and we pass a noop tar pipeline to the worker.
This makes introspecting the job-queu api using curl a bit more
pleasant.
Signed-off-by: Tom Gundersen <teg@jklm.no>
This is by no means done, and needs more tests, docs and bugfixes,
but push it early so we have a common base to work on.
Based on work by Martin Sehnoutka.
Signed-off-by: Tom Gundersen <teg@jklm.no>
The list of changes between the committed blueprint and its workspace
are returned when a user requests the diff. Each change includes the
new(added) or the old(removed) package.
If a package had version "*" and its name-version would be "name-*".
This would match all packages containing "name" in their name. Instead
the name-version is "name-*-*" so it matches any version of the package.
Keep main.go files under cmd/ and internal libraries under internal/.
This will allow us to add more exutables under cmd/ (whereas only one
was possible when main.go was kept in the root).
Signed-off-by: Tom Gundersen <teg@jklm.no>
