Import a new `NEWS.md` file with the changelog for each release. This is
targetted at distributors, so it should contain information on new
features, modified features, and anything important to packagers. This
is not a replacement for the git-changelog, but rather a human-readable
instruction to packagers what needs to be changed when using the new
release.
Additionally, copy `make release` from *osbuild* to help in creating new
release entries in NEWS.md.
This aligns the layout of `README.md` with the osbuild project. It now
has a clear structure with individual sections that we can continue to
improve on.
This tries to salvage most of the information that was previously in
README.md, but removes the bits and pieces that were either moved into
the osbuild-composer(7) man-page, or feels misplaced in a project
readme.
This adds `make man` with SRCDIR and BUILDDIR support. This is copied
from *osbuild*. Since `make man` will be the official way to build the
man-pages, lets also import `make help` and some documentation for the
Makefile.
Create a new man-page source for `osbuild-composer(7)`. This will be
the overview man-page for composer, as well as a good entrypoint to
learn about the entire osbuild setup.
For now, just include some basic information, as well as copy the bits
from README.md that make sense.
Contributions welcome! This could be a lot more verbose and helpful.
Avoid overlong lines in markdown files. This does not affect the
rendered output, but makes it a lot easier to navigate through the file
from a text-editor when editing. Furthermore, it improves *Diffs* of
our commits, and allows reading markdown without rendering it first.
On Fedora, the `%gobuild` macro turns off go modules and sets gopath to
installed libraries (in `/usr/share/gocode`).
When building the test binaries, we used `go test -c` directly, which
downloaded the libraries into GOPATH. That's wasteful and doesn't work
in mock (without internet). Replicate what `%gobuild` does by setting
`GO111MODULE=off` and `GOPATH` to the correct value.
RHEL uses modules as intended. No change is necessary.
If a compose was interrupted by restarting osbuild-composer it should be
set to failed at startup. This was not working because imgBuild is a
temporary variable, the value stored in ImageBuild needs to be modified
directly.
coveralls doesn't work from GitHub actions. Its "github" service type
uses the GITHUB_TOKEN from the action, which only has read access when
invoked from a forked repository.
codecov gets this right: it validates that an uploaded coverage file
originated from a GitHub action run by asking GitHub, and then uses its
OAuth credentials (through the Marketplace App) to comment and set
status.
Also, coveralls requires a third-party package to convert go's coverage
report to a format it understands. codecov detects the format
server-side. It also handles go's coverage format better: it highlights
lines with "some coverage" in yellow (coveralls has no concept of this).
rpmkeys in RHEL-8.1 fails if there is no trailing newline, so just
add it to all the keys for consistency. The fedora keys already
had this.
Signed-off-by: Tom Gundersen <teg@jklm.no>
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.
