Also include the GPG keys. When we first started testing we were
testing against nightlies, whose packages were not signed. But
when using released content (which is signed) the GPG keys are
required.
Signed-off-by: Tom Gundersen <teg@jklm.no>
In PR#395 we discussed the spelling of archs vs. arches and we agreed to
use arches. This patch only renames the public method `ListArchs`in the
`Distro` interface.
Now that these are no longer used for image testsing, they do not need
to be static. Add the standard updates and modular repositories.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Now that the shipped repositories are no longer used for the tests,
we are no longer dependent on being reproducible, so using metalink
is ok.
This stil suffers from the fact that the mirror best for composer
is chosen, which may not be the same as the mirror best for the
worker. However, this sholud still be better than the round-robin
mirror, se we use this until proper metalink implementation is
in place.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Rather than use the round-robin mirror, use a fixe stable one.
We should not over-use this, but it seems the round-robin one is
simply too unstable for our tests.
Eventually, we want to use metalink here instead, but we need to
rework the file source first, so we can do that in a way that
does not make the tests dependent on the time/place the test
case was generated (currently the URL to a specific mirror ends
up pinned in the test-case).
Signed-off-by: Tom Gundersen <teg@jklm.no>
Require repository informaiton to be passed as input, rather than
read from the current directory.
Reading from the repository informaiton meant to be used by weldr
has several drawbacks.
- it makes it impractical to use the tool outside a git checkout
- it makes it awkward to adapt the repositories to different use
cases
- it means that the shipped repositories cannot be extended with
update repos, as the same repos are used for testing, and that
would render our tests non-reproducible.
Overall, we are moving towards making repositories something the
caller must always pass in, rather than something that composer
maintains. For the weldr API we need to keep working as before,
but for new APIs we are avoiding that.
Signed-off-by: Tom Gundersen <teg@jklm.no>
This means that the unit tests no longer need to load the
repositories from the git repo, and in a follow-up, osbuild-composer
won't need to either.
By splitting the repositories used for testing from the system
repositories available through the weldr API we are able to extend
the system repositories without affecting the reproducibility of
the tests.
Signed-off-by: Tom Gundersen <teg@jklm.no>
The API allowed composes to have multiple architectures, image
types and repositories. Turns out that's not exactly what we want
it is not clear how to combine the lits of each. Each architecture
might not combine with each image type, and it is not clear which
repositories are need for each image build. Lastly, while allowing
different image builds to have different distros in the same
compose does not appear immediately useful, there is no particular
reason to disallow that. This patch reworks the way composes are
specified.
The intention remains the same, to be able to submit several image
builds as one compose. But rather than taking arrays of image types
and architectures, take one array of image builds instead, each of
which consists of one distro, one architecture, one image build and
an array of repositories.
In a follow-up patch they will also each contain an array of upload
targets.
This means that each image build will have the same sort of structure
as a compose request in the weldr API. The reason we want to submit
an array of them rather than have them as individual composes, is that
in a follow-up patch we will introduce the concept of a "finalizer",
or "call-back" or something to that effect, which will be triggered
when all the images have been built successfully. The use-case is,
as always, koji, which requires this.
Signed-off-by: Tom Gundersen <teg@jklm.no>
The main reason here is not to make sure we have the right set of build
packages, but rather to make sure the pointer hierarchy (distro->arch->
image type) works as expected.
This patch uses the same approach as fedora31 few commits ago. It moves
the arch pointer to the imageType struct and sets it while creating the
distro->arch->image type hierarchy in the setImageType function. The
rest of the patch is just renaming.
It uses the same approach as fedora31 few commits ago. The pointer to
distro is moved to "arch" and "arch" now contains a map of allowed
image types for each arch.
Also include setArches and setImageTypes helper functions to ease the
creation of pointers from the structures to a parent structure while
creating the distro->arches->image types hierarchy.
Previously we had to type the name of the architecture and image type
multiple times (in the definition, when inserting it into each parent
structure etc.) and it would get even worse because we would have to do
the same for all distros. These helper functions make it less error
prone by copying the name in the function automatically.
The former one was just a wrapper to the second one. In this patch I
removed the fedora31ImageType struct and instead moved the pointer to
the imageType struct. The previous solution always created a new wrapper
and returned it to the called. This new solution creates a shallow copy
of imageType, assignes arch field, and then returns the result to the
caller. It should achieve the same without the additional wrapper.
This information is now provided only when an architecture is specified,
so it is necessary to first obtain object implementing the Arch interface
then object implementing the ImageType interface and then you can get
the filename and mime type.
Tests are changed accordingly to the new API.
The method is available in the Distro interface, but the distro does not
have the information needed to provide this kind of information any
more. The logic is now split into Arch and ImageType interfaces. This
patch will allow us to get rid of some old code and move forward.
The mock server used by unit tests is slightly different than the
running server, mostly related to package names that are hard-coded.
This adds a bool to testState that can be used in the tests to alter the
expected behavior. It should be used as little as possible.
With this change the integration tests can now also be run as unit tests
against the mocked server. The way it works is this:
internal/client/unit_test.go sets up the mock server and is built
when the `integration` build tag is *not* included.
internal/client/integration_test.go sets up the connection to an
existing server and is built when the `integration` build tag *is*
included.
The test code is built and run for both cases.
Currently they all pass for the integration test run. The unit test
cases need some work because the mocked server isn't a real server with
real depsolving and package lists. A future commit will fix this.
Copy weldrcheck's utils.go into client, switch to using TestState struct
to hold global test data. Only build unit_test.go if integration has not
been selected.
This is in preparation to moving weldrcheck code into client *_test.go
files so that the test code can be shared and run against a mock server
during unit testing, or against a running WELDR API server during
integration testing.
This is the start to document the image types that osbuild-composer
produces on a higher level than the code in the `distro` package.
The idea is to document the purpose for each of the image types as well
as the reasons why deviating from a standard install is necessary.
The helper functions were never used, we should aim to use the
osbuild types just as regular structs for serialization purposes.
Signed-off-by: Tom Gundersen <teg@jklm.no>
systemctl list-unit-files doesn't produce machine readable output.
parse_unit_files isn't very good at reading it and can produce duplicate
records.
This commit fixes it by deduplicating and sorting the units. This is a bit
hacky solution, but should work just alright. In the future we might
dump list-unit-files and do the job ourself, but let's not recreate the
systemd logic for now.
We require passing the address from the unit file. Do the same for the
socket, using host:port syntax.
Overriding the port was broken before, because we unconditionally
appended ":8700" to every address.
Introduce a mandatory argument `address`, which is interpreted as a path
to a unix socket when `-unix` is given or a network address otherwise.
Move the default path to the service file.
Add a more useful usage message when passing `-help` or no arguments.
This moves the client code into the same package as the server code,
which makes it easier to change (and version) the two in sync. Also, it
will allow to make some structs private to the jobqueue package and to
test `Client`.
Also rename it to jobqueue.Client.
Use the default dialing functions for tcp connections and set the tls
config on the transport directly. This makes the code easier to follow,
because the only special case is overriding the DialContext() for unix
connections.
The packaging guidelines requires that these provides and obsoletes stays
in the spec file for 2 fedora versions. The name change was introduced in
Fedora 32, there the lines should be removed in F34.
In the new spec file, the tests-related code is always at the bottom of the
containing block to make the conditional code easier to read. Do the same
in the old spec file.
Also, in the new spec file, some whitespaces are different (rpmlint reported
mix used of tabs and spaces), let's do the same changes in the old spec file.
